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第 三 章 模型 


本 章 ， 我 们 会 讨论 以 下 话题 : 


类 图 表 
。 模型 的 结构 模式 


e 模型 的 重要 性 


MATV4C 


在 Dijango 中 ， 模 型 就 是 类 ， 该 类 提供 了 一 种 处 理 数 据 库 的 面向 对 象 方法 。 通 常 ， 每 个 类 都 引 
用 一 个 数据 库 表 ， 每 个 属性 都 引用 一 个 数据 库 列 。 你 可 以 使 用 一 个 自动 生成 的 API 来 查询 这 些 
表 。 


模型 是 很 多 其 他 组 件 的 基础 。 只 要 你 有 一 个 模型 ， 你 可 以 很 快 地 得 到 模型 admin， 模 型 表单 ， 
以 及 所 有 类 型 的 通用 视图 。 每 种 情况 下 ， 都 需要 你 编写 一 两 行 代码 ， 这 样 可 以 让 它 看 上 去 没 
有 太 多 魔法 。 


模型 也 被 用 在 更 多 的 超出 你 期 望 的 地 方 。 这 是 因为 Django 可 以 以 多 种 方式 运行 。Dijango 的 一 
些 切入 点 如 下 : 


e 常见 的 web 请 求 -响应 d 
. BTE 令 和 

e 管理 命 

。 测试 脚本 

© 异步 任务 队列 ， 比 如 Celery 


几乎 所 有 的 情况 中 ， 模 型 模块 都 需要 导入 (作为 django.setup() 的 一 部 分 ) 。 因 此 ， 最 好 保证 
模型 远离 任何 不 必要 的 依赖 ， 或 者 导入 任何 的 其 他 Django 组 件 ， 比 如 视图 。 


简 而 言 之 ， 恰 当地 设计 模型 是 件 十 分 重要 的 事情 。 现 在 ， 让 我 们 从 SuperBook 模 型 设计 开 
始 。 
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注释 

自 带 午餐 便当 

* 作 者 注释 : SuperBook 项 目的 进度 会 以 这 样 的 一 个 盒子 来 表现 。 你 可 以 跳 过 这 个 盒子 ， 
但 是 在 web 应 用 项 目 中 的 情况 下 ， 你 缺少 的 是 领悟 ， 经 验 。 

史 荫 夫 和 客户 的 第 一 周一 “超级 英雄 情报 监控 (简称 为 S.H.I.M) 。 简 单 来 说 ， 这 是 一 个 
大 杂烩 。 办 公 室 是 非常 未 来 化 的 ， 但 是 不 论 做 什么 事情 都 需要 上 百 个 审核 和 签字 。 





作为 Django 开发 者 的 领队 ， 史 蒂 夫 已 经 配置 好 了 中 型 的 运行 超过 两 天 的 4 人 台 虚 拟 机 。 第 二 
天 的 一 个 早晨 ， 机 器 自己 不 机 而 飞 了 。 一 个 附近 的 清洁 机 器 人 说 ， 机 器 被 法 务 部 们 给 带 
走 了 ， 他 们 要 对 未 经 审核 的 软件 安装 做 出 处 理 。 


然而 ，CTO 哈 特 给 予 史 幕 夫 了 极 大 的 帮助 。 他 要 求 机 器 在 一 个 小 时 之 内 完好 无 损 地 给 还 
回去 。 他 还 对 SuperBook 项 目 做 出 了 提前 审核 以 避免 将 来 可 能 出 现 的 任何 阻碍 。 


那个 下 午 的 稍 晚 些 时 候 ， 史 蒂 夫 给 他 带 了 一 个 午餐 便当 。 身 着 一 件 米 色 外 套 和 浅 蓝 色 牛 
仔裤 的 哈 特 如 约 而 至 。 尽 管 高 出 周围 人 许多 ， 有 着 清 更 面庞 的 他 依旧 那么 帅气 ， 那 么 平 
易 近 人 。 他 问 史 蒂 夫 如 果 他 之 前 是 否 尝试 过 构建 一 个 60 年 代 的 超级 英雄 数据 库 。 

" 咽 ， 对 的 ， 是 哨兵 项 目 么 ?9“， 史 东 夫 说 道 。" 是 我 设计 的 。 数 据 库 看 上 去 被 设计 成 了 一 
个 条 目 - 属 性 - 值 形式 的 模式 ， 有 些 地 方 我 考虑 用 反 模 式 。 可 能 ， 这 些 天 他 们 有 一 些 超 级 英 
雄 属 性 的 小 想法 。 哈 特 几 乎 等 不 到 听 完 最 后 一 句 ， 他 压低 嗓门 道 :“ 没 错 。 是 我 的 错 。 另 
外 ， 他 们 只 给 了 我 两 天 来 设计 整个 架构 。 他 们 这 是 在 要 我 老 命 啊 I 


听 了 这 些 ， 史 莆 夫 的 嘴巴 张 的 大 大 的 ， 三 明治 也 卡 在 了 嘴 里 。 哈 特 微笑 着 道 : “当然 了 ， 
没 


我 还 没有 尽 全 力 来 做 这 件 事 。 只 要 它 成 长 为 100 万 美元 的 单子 ， 我 们 就 可 以 多 花 点 时 间 在 
这 该 死 的 数据 库 上 了 。SuperBook 用 它 就 能 分 分 钟 完事 的 ， 小 史 你 说 呢 ?” 


史 带 夫 微微 点 头 称 是 。 他 从 来 没有 想 过 在 这 么 样 的 地 方 将 会 有 上 百 万 的 超级 英雄 出 现 。 


模型 搜寻 


这 是 我 们 头 一 次 见识 到 SuperBook 中 模型 。 我 们 只 表示 了 基本 模型 ， 以 及 类 图 表 中 的 表单 的 
基本 关系 ， 这 也 是 早期 尝试 中 所 特有 的 情况 : 


N 


JA 
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post 
UU Post 


* forpost 


commented by * 
Comment 


Profile 


1 
1 
1 


One to Many 


Many to Many 





让 我 们 暂且 忘掉 模型 ， 来 谈 谈 我 们 正在 构建 的 对 象 的 术语 。 每 个 用 户 都 有 一 个 账户 。 用 户 可 
以 写 多 个 回复 或 者 多 篇 文章 。Like 同 时 关联 到 了 一 个 独立 用 户 /文章 组 合 。 


建议 你 为 自己 的 模型 画 一 个 这 样 类 图 表 。 这 一 步 的 某 些 属性 缺失 了 ， 不 过 你 可 以 在 之 后 对 它 
们 进行 详细 补充 。 只 要 整个 项 目 用 图 表 表 现 出 来 ， 便 可 以 轻松 地 分 离 app 了 。 


下 面 是 创建 这 个 表现 的 一 些 提示 : 


e 盒子 表示 条 目 ， 它 将 成 为 模型 。 

e 名 词 通常 作为 条 目的 终止 。 

箭头 是 双向 的 ， 它 代表 了 Django 中 的 三 种 关系 类 型 其 中 的 一 种 : 一 对 一 ， 一 对 多 (通过 
外 键 实现 ) ， 和 多 对 多 。 

字段 表明 在 模型 中 根据 条 目 - 关 系 模型 (ER-modle) 定义 了 一 对 多 关系 。 换 句 来 说 ， 星 
号 就 是 声明 外 键 的 地 方 。 


类 图 表 可 以 映射 到 下 面 的 Django 代 码 中 (分布 于 多 个 应 用 之 中 ) 


class Profile(models.Model): 
user = models.OnToOneField(User ) 


class Post(models.Model): 
posted by = models.ForeignKey(User) 


class Comment (models.Model): 
commented by - models.ForeignKey(User) 
for post - models.ForeignKey(Post) 
class Like(models.Model): 


liked by - models.ForeignKey(User) 
post - models.ForeignKey(Post) 


后 面 ， 我 们 不 会 直接 地 引用 User， 而 是 使 用 更 常见 的 settings.AUTH_USER_MODEL 来 。 


把 model.py 分 到 多 个 文件 中 去 


就 像 多 数 的 Django 组 件 那 样 ， 一 个 大 的 model.py 文 件 可 以 在 一 个 包 内 分 割 为 多 个 文 
件 。package 通 过 一 个 目录 来 实现 ， 它 包含 多 个 文件 ， 目 录 中 的 一 个 文件 必须 是 一 个 称 
为 init .py 特殊 文件 。 


所 有 可 以 在 包 级 别 中 暴露 的 定义 都 必须 在 _ init .py 里 使 用 全 局 变量 域 定义 。 例 如 ， 如 果 我 
1112- 9l model.py $1 z z- &j 3€ > models 3: fF 3 P 89 st E 3t fF * 1639 » postable.py > post.py?e 
comment.py, 之 后 init .py 包 会 像 这 样 : 


from postable import Postable 
from post import Post 
from commnet import Comment 


现在 你 可 以 像 之 前 那样 导入 models.Post 了 。 


E init .py 包 中 的 任何 其 他 代码 都 会 在 包 运 行 时 被 导入 。 因 此 ， 它 是 一 个 任意 级 别 包 初始 
化 代码 的 理想 之 地 。 


结构 模式 


本 节 和 包含 多 个 帮助 你 设计 和 构建 模型 的 设计 模式 。 


模式 -规范化 模型 
问题 : 通过 设计 ， 模 型 实例 的 重复 数据 引起 数据 不 一 致 。 


解决 方法 : 通过 规范 化 ， 分 解 模 型 到 更 小 的 模型 。 使 用 这 些 模 型 之 间 的 逻辑 关系 来 连接 他 
们 。 


问题 细节 


想象 一 下 ， 如 果 某 人 用 下 面 的 方法 设计 Post 表 (省 略 部 分 列 ) 


超级 英雄 的 名 字 消息 发 布 时 间 
Captain Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:15 
Professor English 应 该 用 “|ls” 而 不 是 “Has" 2012/07/07/07:17 
Captain Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:18 
Capt. Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:19 


我 希望 你 注意 到 了 在 最 后 一 行 的 超级 英雄 名 字 和 之 前 不 一 致 (船长 一 如 既往 的 缺乏 耐心 ) o 


如 果 我 们 看 看 第 一 列 ， 我 们 也 不 确定 哪 一 个 拼写 是 正确 的 
Captain Temper 或 者 capt.Temper 。 这 就 是 我 们 要 通过 规范 化 消除 的 一 种 数据 宛 余 。 





详解 

在 我 们 看 下 完整 的 规范 方案 ， 让 我 们 用 Django 模 型 的 上 下 文 来 个 关于 数据 库 规 范 化 的 简要 说 
B] o 

规范 化 的 三 个 步骤 


规范 化 有 助 于 你 更 有 效 地 的 存储 数据 库 。 只 要 模型 完全 地 的 规范 化 处 理 ， 他 们 就 不 会 有 宛 余 
的 数据 ， 每 个 模型 应 该 只 包含 远 辑 上 关联 到 自身 的 数据 。 


这 里 给 出 一 个 简单 的 例子 ， 如 果 我 们 规范 化 了 Post 表 ， 我 们 就 可 以 不 模棱两可 地 引用 发 布 消 
息 的 超级 英雄 ， 然 后 我 们 需要 用 一 个 独立 的 表 来 隔离 用 户 细节 。 默 认 ，Dijango 已 经 创建 了 用 
户 表 。 因 此 ， 你 只 需要 在 第 一 列 中 引用 发 布 消息 的 用 户 的 ID， 一 如 下 表 所 示 : 


用 户 1D 消息 发 布 时 间 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:15 
8 应 该 用 "ls” 而 不 是 “Has" 2012/07/07/07:17 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:18 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:19 


现在 ， 不 仅仅 相同 用 户 发 布 三 条 消息 的 清楚 在 列 ， 而 且 我 们 可 以 通过 查询 用 户 表 找到 用 户 的 
正确 的 名 字 。 


通常 来 说 ， 你 会 按照 模型 的 完全 规 规范 化 表 来 设计 模型 ， 也 会 因为 性 能 原因 而 有 选择 性 地 非 
规范 化 设计 。 在 数据 库 中 ，Normal Forms 是 一 组 可 以 被 应 用 于 表 ， 确 保 表 被 规范 化 的 指南 。 
一 般 我 们 建立 第 一 ， 第 二 ， 第 三 规范 表 ， 尽 管 他 们 可 以 递增 至 第 五 规范 表 。 


这 接 下 来 的 例子 中 ， 我 们 规范 化 一 个 表 ， 创 建 对 应 的 Django 模 型 。 想 象 下 有 个 名 字 称 
做 “Sightings” 的 表格 ， 它 列 出 了 某 人 第 一 次 发 现 超级 英雄 使 用 能 力 或 者 特异 功能 。 每 个 条 目 都 
提 到 了 已 知 的 原始 身份 ， 超 能 力 ， 和 第 一 次 发 现 的 地 点 ， 包 括 维 度 和 经 度 。 


第 一 次 使 用 记录 (维度 ， 经 度 ， 国 家 ， 时 


Ea 么 信 自 25 
A F 原始 信息 能 力 间 ) 
Blitz Alien Freeze Flight +40.75, -73.99; USA; 2014/07/03 23:12 
Hexa Scientist hc 435.68, 4139.73; Japan; 2010/02/17 20:15 
Traveller | Billonaire Time travel *43.62, *1.45, France; 2010/11/10 08:20 


E m 65 3,32 2 3E 42 FX A http://www.golombek.com/locations.html. 
第 一 范式 表 (1NF) 
确认 一 下 的 第 一 张 范式 表格 ， 这 张 表 必 须 含 有 : 


多 个 没有 属性 (cell) 的 值 
一 个 主键 作为 单独 一 列 或 者 一 组 列 (合成 键 ) 


让 我 们 试 着 把 表格 转换 为 一 个 数据 库 表 。 明 显 地 ， 我 们 的 Power 列 破坏 了 第 一 个 规则 。 


更 新 过 的 表 满 足 第 一 范式 表 o 主键 (用 一 个 ^ 标记 ) 是 Name 和 Power 的 合并 对 于 每 一 排 
它 都 应 该 是 唯一 的 。 


Name* Origin Power* Latitude Longtitude ^ Country Tin 
Blitz Alien Freeze  +40.75170 -73.99420 USA a6 
Blitz Alien Flight *40.75170 -73.99420 USA jn 

-— ae 2010/( 

Hexa Scientist Telekinesis +35.68330  *139.73330 Japan 20: 

eT 2010 

Hexa Scientist Filght 19509330 +139.73330 Japan 20: 

ed ; 2010/ 

Traveller Billionaire Time tavel +43.61670 +1.45000 France 08: 
第 二 范式 表 


第 二 范式 表 必 须 满足 所 有 第 一 范式 表 的 条 件 。 此 外 ， 它 必须 满足 所 有 非 主 键 列 都 必须 依赖 于 
整个 主键 的 条 件 。 


我 们 注意 到 在 前 面 的 表 中 origin 只 依赖 于 超级 英雄 ， 即 ， Name 。 不 论 我 们 谈论 的 是 哪 一 
个 Power 。 因 此 ， Origin 不 是 完全 地 依赖 于 合成 组 件 - Name 和 Power 。 


文 里 ， 让 我 们 只 取出 原始 信息 到 一 个 独立 的 ， 称 做 Origins 的 表 : 


Name* Origin 
Blitz Alien 
Hexa Scientist 
Traveller Billionaire 


现在 Sightings 表 更 新 为 兼容 第 二 范式 表 ， 它 大 概 是 这 个 样子 : 


Name* Power* Latitude Longtitude Country Time 

Blitz Freeze  +40.75170 -73.99420 Usb. fen e 

Blitz Flight +40.75170 -73.99420 USA 7 
Hexa Telekinesis +35.68330 +139.73330 Japan eee ead 

Hexa Filght | +35.68330 413973330 | Japan | 201002119 
Traveller Time tavel +43.61670 | 1.45000 Fiance 20 A 0 
第 三 范式 表 


在 第 三 范式 表 中 ， 比 表格 必须 满足 第 二 范式 表 ， 而 且 应 该 额外 满足 所 有 的 非 主键 列 都 直接 依 
赖 整个 主键 ， 而 且 这 些 非 主 键 列 都 是 互相 独立 的 这 个 条 件 。 


考虑 下 country 类 。 给 出 维度 和 经 度 ， 你 可 以 轻松 地 得 出 country. 列 。 即 使 观测 到 超级 英雄 
的 地 方 依赖 于 Name-Power 合成 键 ， 但 只 是 间 s 8 


因此 ， 我 们 把 详细 地 址 分 离 到 一 个 独立 的 国家 表格 中 : 
Location ID Latitude* Longtitude* Country 


1|440.75170|-73.99420|USA| 2|+35.68330|+139.73330|Japan| 
3|+43.61670|+1.45000|France| 


现在 sightings 表格 的 第 三 范式 表 大 抵 如 此 : 


User 1D* Power* Location ID Time 


2 Freeze 1 2014/0703 23:12 
2 Flight 1 2013/03/12 11:30 
4 Telekinesis 2 2010/02/17 20:15 
4 Flight 2 2010/02/19 20:30 
7 Time tavel 3 2010/11/10 08:20 


如 之 前 所 做 的 那样 ， 我 们 用 对 应 的 user ID 替换 了 超级 英雄 的 名 字 ， 这 个 用 户 ID 用 来 引用 用 
户 表格 。 


Django 模 型 


现在 我 们 可 以 看 看 这 些 规范 化 的 表格 可 以 用 来 表现 Django 模 型 。Django 中 并 不 直接 支持 合成 
键 。 这 里 用 到 URAXIRAR 用 代理 键 ， 以 及 在 Meta 类 中 指定 unique together 属性 : 


class Origin(models.Model): 
superhero = models.ForeignKey(settings.AUTH USER MODEL) 
origin = models.CharField(max length-100) 


class Location(models.Model): 
latitude - models.FloatField() 
longtitude - models.FloatField() 
country = models.CharField(max_length=100) 


class Meta: 
unique_together = ("latitude", "longtitude") 


class Sighting(models.Model): 
superhero = models.ForeignKey(settings.AUTH USER MODEL) 
power = models.CharField(max_length=100) 
location - models.ForeignKey(Location) 
sighted on - models.DateTimeField() 


class Meta: 
unique together - ("superhero", "power") 


性 能 和 非 规范 化 


规范 化 可 能 对 性 能 有 不 利 的 影响 。 随 着 模型 的 增长 ， 需 要 应 答 查询 的 连接 数 也 随 之 增加 。 例 
如 ， om 冻 能 力 的 超级 英雄 的 数量 ， 你 需要 连接 四 个 表格 。 先 前 的 内 容 规范 
后 ， 任 何 信息 都 可 以 通过 查询 一 个 单独 的 表格 被 找到 。 


你 应 该 设计 模式 以 保持 数据 规范 化 。 这 可 以 维持 数据 的 完整 。 然 而 ， 如 果 你 面临 扩展 性 问 
题 ， 你 可 以 有 选择 性 地 从 这 些 模型 取得 数据 以 生成 非 规 范 化 的 数据 。 
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实践 因 设 计 而 规范 ， 又 因 优化 而 非 规 范 


例如 ， 在 一 个 确定 的 国家 中 计算 观测 次 数 是 非常 普通 的 ， 然 后 将 观测 次 数 作为 一 个 附加 
的 字段 到 Location 模型 。 现 在 ， 你 可 以 使 用 Django ORM 继承 其 他 的 查询 ， 而 不 是 一 个 
4 f ME 。 


然而 ， 你 需要 在 每 次 添加 或 者 移 除 观 测 时 更 新 这 个 计数 。 你 需要 添加 该 计算 到 Singhting 
的 save 方法 ， 添 加 一 个 信号 处 理 器 ， 基 至 使 用 一 个 异步 任务 去 计算 。 





如 果 你 有 一 个 跨越 多 个 表 的 负责 查询 ， 比 如 国家 的 超 能 力 计 算 ， 你 需要 创建 一 个 独立 的 
非 规范 表格 。 就 像 前 面 那样 ， 我 们 需要 在 每 一 次 规范 化 模型 中 的 数据 改变 时 更 新 这 个 非 
规范 的 表格 。 


令 人 惊讶 的 是 非 规范 化 在 大 型 的 网 站 中 是 非常 普遍 的 ， 因 为 它 是 数 度 和 存储 空间 两 者 之 
间 的 折衷 。 今 天 的 存储 空间 已 经 比较 便宜 了 ， 然 而 速度 也 是 用 户 体验 中 至 关 重 要 的 一 
环 。 因 此 ， 如 果 你 的 查询 耗 时 过 于 久 的 话 ， 那 么 就 需要 考虑 非 规范 化 了 。 


我 们 应 该 一 直 使 用 规范 化 吗 ? 
过 多 的 规范 化 是 是 件 不 必要 的 事 。 有 时 候 ， 它 可 以 引入 一 个 非 必需 的 能 够 重复 更 新 和 查询 的 
表格 。 


例如 ， 你 的 User 模型 或 许 有 好 多 个 家 庭 地 址 的 字段 ， 你 可 以 规范 这 些 字段 到 一 个 Address 模 
型 中 。 可 是 ， 多 数 情 况 下 ， 把 一 个 额外 的 表 引 进 数据 库 是 没有 必要 的 。 


a abdo esum Do COMIS 重 构 之 前 仔细 地 衡量 每 个 非 规范 化 的 机 会 ， 对 
性 能 和 速度 上 做 出 一 个 折 让 的 选择 。 

模式 -模型 mixins 

问题 : 明显 地 模型 含有 重复 的 相同 字段/ 或 者 方法 ， 违 反 了 DRY 原 则 。 


方案 : 提取 公共 字段 和 方法 到 各 种 不 同 的 可 重复 使 用 的 模型 mixins 中 。 
问题 细节 
设计 模型 之 时 ， 你 或 许 某 些 个 公共 属性 或 者 行为 跨 类 共享 。 烈 日 ， Post 和 comment 模型 需要 


一 直 跟 踪 自 己 的 created 日 期 和 modified 日 期 。 手 动 地 复制 -粘贴 字段 和 它们 所 关联 的 方法 并 
不 符合 DRY 原 则 。 


由 于 Django 的 模型 是 类 ， 像 合成 以 及 继承 这 样 的 面向 对 象 方法 都 是 可 以 选择 的 解决 方案 。 然 
而 ， 合 成 (具有 包含 一 个 共享 类 实例 的 属性 ) 需要 一 个 额外 的 间接 地 访问 字段 的 标准 。 


继承 是 有 技巧 的 。 我 们 使 用 一 个 post 和 comment 的 公共 基 类 。 然 而 ， 在 Django 中 有 三 种 类 型 
的 继承 : concrete (具体 ) , abstract (45 €) , feproxy (代理 ) 。 


具体 继承 的 运行 是 源 于 基 类 ， 就 像 你 在 Python 类 中 通常 用 到 的 那样 。 不 过 ， edd T 
个 基 类 将 被 映射 到 一 个 独立 的 表 中 。 每 次 你 访问 基本 字段 时 ， 都 需要 一 个 准确 的 连接 。 这 会 
带 来 非常 糟糕 的 性 能 问题 。 


代理 继承 只 能 添加 新 的 行为 到 父 类 。 你 不 能 够 添加 新 字段 。 因 此 ， 这 种 情况 下 它 也 不 大 好 
用 。 


最 后 ， 我 们 只 有 托付 于 抽象 继承 了 。 


详解 


抽象 基 类 是 用 于 模型 之 间 共 享 数据 和 行为 的 游戏 简洁 方案 。 当 你 定义 一 个 基 类 时 ， 它 在 数据 
中 没有 创建 任何 与 之 对 象 的 表 。 反 而 ， 这 些 字段 RRA DIRK PAE 。 


访问 抽象 基 类 字段 不 要 JoIN 语句 。 有 支配 的 字段 结构 表 也 是 不 解 自 明 的 。 对 于 这 ， 大 
多 数 的 Django 项 目 都 使 用 抽象 基 类 实现 公共 字段 或 者 方法 。 


使 用 抽象 模型 是 局 限 的 : 


它们 不 能 够 拥有 外 键 或 者 来 自 其 他 模型 的 多 对 多 字段 。 
它们 不 能 够 被 实例 化 或 者 保存 。 
它们 不 能 够 直接 用 在 查询 中 ， 因 为 它 没有 管理 器 。 


下 面 是 post 和 comment 类 如 何 使 用 一 个 抽象 基 类 初始 设计 的 : 


class Postable(models.Model): 
created = models.DateTimeField(auto_now_add=True) 
modified = modified.DateTimeField(auto_now=True) 
message = models. TextField(max_length=500) 


class Meta: 
abstract = True 


class Post(Postable): 


class Comment(Postable): 


要 将 一 个 模型 转换 到 抽象 基 类 ý 需要 在 它 的 内 部 meta 类 中 写 上 abstract = True 。 这 里 
的 postable 是 一 个 抽象 基 类 。 ae ， 它 不 是 那么 的 可 复 用 。 


实际 上 ， 如 果 有 一 个 类 含有 created 和 modified 字段 ， 我 们 在 后 面 就 可 以 在 附近 的 任何 需要 
时 间 惟 的 模型 中 重复 使 用 这 个 时 间 稚 功能 。 


模型 mixins 


模型 mixins 是 一 个 可 以 把 抽象 基 类 当 作 父 类 来 添加 的 模型 。 不 像 其 他 的 语法 ， 比 如 Java 那 
样 ，Python 支 持 多 种 继承 。 因 此 ， 你 可 以 列 出 一 个 模型 的 任意 数量 的 父 类 。 


Mixins 应 该 是 互相 垂直 的 而 且 易 于 组 合 的 。 把 一 个 mixin 放 进 基 类 的 列表 ， 这 些 mixin 应 该 可 以 
正常 运行 。 这 样 看 来 ， 它 们 在 行为 上 更 类 似 于 合成 而 非 继承 。 


较 小 的 mixin 的 会 更 好 。 不 论 何 时 一 个 mixin 变 得 腔 肿 ， 而 且 又 违反 了 独立 响应 原则 ， 就 要 考虑 
把 它 重 构 到 一 个 更 小 的 类 。 就 让 一 个 mixin 一 次 做 好 一 件 吧 。 


在 前 面 的 例子 中 ， 模 型 mixin 用 于 更 新 created 和 modified 的 时 间 可 以 轻松 地 分 解 出 来 ， 一 如 
下 面 代码 所 示 : 


class TimeStampedModel(models.Model): 
created = modified.TimeStampModel(auto_now_add=True) 
modified = modified.DateTimeField(auto_now=True) 


class Meta: 


abstract = True 


class Postable(TimeStampedModel): 
message = models.TextField(max length-500) 


class Meta: 
abstract - True 


class Post(Postable): 


class Comment(Postable): 


我 们 现在 有 两 个 超 类 了 。 不 过 ， 功 能 之 间 都 完全 地 独立 。mixin 可 以 分 离 到 自己 的 模块 之 内 ， 
并 且 另 外 的 上 下 文中 被 复 用 。 


模式 -用 户 账 户 


问题 : 每 一 个 网 站 都 存储 一 组 不 同 的 用 户 账户 细节 。 然 而 ，Django 的 内 建 User 模 型 家 在 针对 
认证 细节 。 


方案 : 用 一 个 一 对 一 关系 的 用 户 模型 ， 创 建 一 个 用 户 账户 类 。 


问题 细节 


Django 提 供 一 个 开 箱 即 用 的 相当 不 错 的 User 模 型 。 你 可 以 在 创建 超级 用 户 或 者 登录 amdin 接 
口 的 时 候 用 到 它 。 它 含有 少量 的 基本 字段 ， 比 如 全 名 ， 用 户 名 ， 和 电子 邮件 。 


然而 ， 大 多 数 的 现实 世界 项 目 都 保留 了 很 多 关于 用 户 的 信息 ， 比 如 他 们 的 地 址 ， 喜 欢 的 电 
影 ， 或 者 它们 的 超 能 力 。 打 Dijango1.5 开 始 ， 默 认 的 User 模 型 就 可 以 被 扩展 或 者 替换 掉 。 不 
过 ， 官 方 文档 极力 推荐 只 存储 认证 数据 ， 即 便 是 在 定制 的 用 户 模型 中 也 是 如 此 《上 毕竟， 用 户 
模型 也 是 所 属于 auth 这 个 app 的 ) 。 


ek 目 是 需要 多 种 类 型 的 用 户 的 。 例 如 ，SuperBook 可 以 被 超级 英雄 和 非 超 级 英雄 所 使 
用 。 这 里 或 许 会 有 一 些 公共 字段 ， 以 及 基于 用 户 类 型 的 不 同 字 段 。 


详解 


官方 推荐 解决 方案 是 创建 一 个 用 户 账户 模型 。 它 应 该 和 用 户 模型 有 一 个 一 对 一 的 关系 。 其 余 
的 全 部 用 户 信息 都 存储 于 该 模型 : 


class Profile(models.Model): 
user = models.OnToOneField(settings.AUTH_USER_MODEL, primary_key=True) 


这 里 推荐 你 明确 的 将 primary key 赋值 为 True 以 阻止 类 似 PostgreSQL 这 样 的 数据 库 后 端 中 
的 并 发 问题 。 剩 下 的 模型 可 以 包含 其 他 的 任何 用 户 详情 ， 比 如 生日 ， 喜 好 色彩 ， 等 等 。 


设计 账户 模型 之 时 ， 建 议 所 有 的 账户 详情 字段 都 必须 是 非 空 的 ， 或 者 含有 一 个 默认 值 。 赁 直 
觉 我 们 就 知道 用 户 在 注册 时 是 不 可 能 填写 完 所 有 的 账户 细节 的 。 此 外 ， 我 们 也 要 确保 创建 账 
户 实例 时 ， 信 号 处 理 器 没有 传递 任何 初始 参数 。 
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理论 上 ， 每 一 次 用 户 模型 的 创建 都 必须 把 对 应 的 用 户 账户 实例 创建 好 。 这 个 操作 通常 利用 信 
号 来 完成 。 例 如 ， 我 们 可 以 使 用 下 面 的 信号 处 理 器 侦 听 用 户 模型 的 post_save 信号 : 


# signals.py 

from django.db.models.signals import post_save 
from django.dispatch import receiver 

from django.conf import settings 

from . import models 


@receiver(post_save, sender-settings.AUTH USER MODEL) 
def create profile handler(sender, instance, created, **kwargs): 
if not created: 
return 
# Create the profile object, only if it is newly created 
profile - models.Profile(user-instance) 
profile.save() 


注意 账户 模型 除了 用 户 实 例 之 外 没有 传递 额外 的 参数 。 


之 前 没有 指定 初始 信号 代码 的 地 方 。 通 常 ， 它 们 在 models.py 中 (这 是 不 可 靠 的 ) 导入 或 者 
执行 。 不 过 ， 随 着 Django 1.7 的 app 载 入 重 构 ， 应 用 初始 化 代码 位 置 的 问题 也 很 好 的 解决 了 。 


首先 ， 为 你 的 应 用 创建 一 个 __init__.py 包 以 引用 应 用 的 ProfileConfig : 


default_app_config = "profile.apps.ProfileConfig" 


ay 
中 


接 下 来 是 app.py 中 ， 子 类 ProfileConfig 的 方法 ， 可 于 ready 方法 中 配置 


# app.py 
from django.apps import AppConfig 


class ProfileConfig(AppConfig): 
name = "profiles" 
verbose_name = "User Profiles" 


def ready(self): 
from . import signals 


随 着 信号 的 配置 ， 对 所 有 的 用 户 来 说 ， 访 问 user. profile 应 应 该 都 返回 一 个 profile 对 象 ， 即 
使 是 最 新 创建 的 用 户 也 是 如 此 。 


Admin 


现在 ， 用 户 的 详情 为 存在 admin 内 的 两 个 不 同 地 方 : Red oe dE ， 在 一 
个 独立 账户 admin 页 面 中 的 相同 用 户 的 补充 账户 详情 。 这 样 做 非常 麻烦 。 


为 了 操作 方便 ， 账 户 admin 可 以 通过 定义 一 个 自 定义 的 UserAdmin 3k AF XI 84 A P admin 
中 : 

# admin.py 

from django.contrib import admin 


from .models import Profile 
from django.contrib.auth.models import User 


class UserProfileInline(admin.StackedInline): 
model = Profile 


class UserAdmin(admin.UserAdmin) : 
inlines = [UserProfileInline] 


admin.site.unregister (User) 
admin.site.register(User, UserAdmin) 


多 账户 类 型 


假设 在 应 用 中 你 需要 几 种 类 型 的 用 户 账户 。 这 里 需要 有 一 个 字段 去 跟踪 用 户 使 用 的 是 哪 一 种 
账户 类 型 。 账 户 数据 本 身 需要 存储 在 独立 的 模型 中 ， 或 者 存储 在 一 个 统一 的 模型 中 。 


建议 使 用 聚合 账户 的 方法 ， 因 为 它 让 改变 账户 类 型 而 不 丢失 账户 细节 ， 并 具有 灵活 性 ， 减 小 
复杂 度 。 在 这 个 房 中 中 ， 账 户 模 型 包含 一 个 所 有 账户 类 型 的 字段 超 集 。 


例如 ，SuperBook 会 需要 一 个 superHero 类 型 账户 ， 和 一 个 ordinary 〈 非 超 集 英雄 ) 账户 。 
它 可 以 用 一 个 独立 的 统一 账户 模型 实现 : 


class BaseProfile(models.Model): 
USER TYPES - ( 
(0, 'Ordinary'), 
(1, 'SuperHero'), 


) 
user = models.OnToOneField(settings.AUTH USER MODEL, primary key-True) 
user type = models.IntegerField(max length-i, null=True, choices-USER TYPES) 


bio = models.CharField(max length-200, blank=True, null=True) 


def str (self): 
return "{}:{:.20}".format(self.user, self.bio or "") 


class Meta: 
abstract - True 
class SuperHeroProfile(models.Model): 
origin = models.CharField(max_length=100, blank=True, null-True) 
class Meta: 
abstract - True 
class OrdinaryProfile(models.Model): 
address = models.CharField(max length-200, blank=True, null=True) 
class Meta: 


abstract - True 


class Profile(SuperHeroProfile, OrdinaryProfile, BaseProfile): 
pass 


[| mc € Ó— M————— ———Ó'— ee 
我 们 组 织 账 户 细 节 到 多 个 抽象 基 类 再 到 独立 的 关系 中 。 Baseprofile 类 包含 所 有 的 不 关心 用 户 
类 型 的 公共 账户 细节 。 它 也 有 一 个 user type 字段 ， 它 持续 追踪 用 户 的 激活 账户 。 
SuperHeroProfile 类 和 ordinaryProfile 类 分 别 包 含 所 有 到 超级 英雄 和 非 超 级 英雄 特定 账户 细 
节 。 最 后 ， 所 有 这 些 基 类 的 profile 类 创建 了 一 个 账户 细节 的 超 集 。 


使 用 该 方法 时 要 主要 的 一 些 细节 o: 


所 有 属于 类 的 字段 或 者 它 抽 象 基 类 都 必须 是 非 空 的 ， 或 者 有 一 个 默认 值 。 
这 个 方法 或 许 会 为 了 每 个 用 户 而 消耗 更 多 的 数据 库 ， 但 是 却 带 来 极 大 的 灵活 性 。 
账户 类 型 的 激活 和 非 激活 字段 都 必须 在 模型 外 部 是 可 管理 的 。 


说 到 ， 编 辑 账户 的 表 必须 显示 合乎 目前 激活 用 户 类 型 的 字段 。 
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模式 -服务 模式 

问题 : 模型 会 变 得 庞大 而 且 不 可 管控 。 当 一 个 模型 不 止 实现 一 个 功能 时 ， 测 试 和 维护 也 会 变 
得 困难 。 


解决 方法 : 重 构 出 一 组 相关 方法 到 一 个 专用 的 service 对 象 中 。 


问题 细节 

富 模型 ， 瘦 视图 是 一 个 通常 要 告诉 Django 新 手 的 格言 。 理 论 上 ， 你 的 视图 不 应 该 包含 任何 其 
他 表现 逻辑 。 

可 是 ， 随 着 时 间 的 推移 ， 代 码 段 不 能 够 放 在 任意 地 点 ， 除 非 你 打算 将 它们 放 进 模型 中 。 很 
快 ， 模 型 会 变 成 一 个 代码 的 垃圾 场 。 


下 面 是 模型 可 以 service 对 象 的 征兆 : 


与 扩展 能 服务 交互 ， 例 如 web 服 务 中 ， 检 查 一 个 用 户 具 有 资格 。 

帮助 任务 不 会 处 理 数据 库 ， 例 如 ， 生 成 一 个 短 链 接 ， 或 者 针对 用 户 的 验证 码 。 
牵涉 到 一 个 短命 的 对 象 时 不 会 存在 数据 库 状态 记录 ， 烈 日 ， 创 建 一 个 和 JAX 调用 的 JSON 响 应 。 
对 于 长 时 间 运 行 的 任务 设计 到 了 多 实例 ， 比 如 Celery 任 务 。 


AUNE 


Django 中 的 模型 遵循 着 激活 记录 模式 。 理 论 上 ， 它 们 同时 封装 应 用 罗 即 数据 库 访 问 。 不 过 ， 
要 记得 保持 应 用 逻辑 最 小 化 。 


在 测试 时 ， 如 果 我 们 发 现 没有 对 数据 库 建 模 的 必要 ， 甚 至 不 会 用 到 数据 库 ， 那 么 我 们 需要 考 
虑 把 分 解 模型 类 。 建 议 这 种 场合 下 使 用 service 对 象 。 

详解 

服务 对 象 是 封装 一 个 服务 或 者 和 系统 儿 独 的 普通 而 老 昌 的 Python 对 得 (POPOs) 。 它们 通常 
保存 在 一 个 独立 的 称 为 service.py 或 者 utils.py 的 文件 。 


例如 ， 像 下 面 这 样 ， 检 查 一 个 Web 服 务 是 否 作 为 一 个 模型 方法 : 
class Profile(models.Model): 


def is_superhero(self): 
url = "http://api.herocheck.com/?q={0}". format ( 
self.user.username 


) 


return webclient.get(url) 


该 方法 可 以 使 用 一 个 服务 对 象 来 重 构 : 


from .services import SuperHeroWebAPI 


def 1s_superhero(self ): 
return SuperHeroWebAPI.is superhero(self.user.username) 


现在 服务 对 象 可 以 定义 在 services.py 中 了 : 


API_URL = "http://api.herocheck.com/?q={0}" 


class SuperHeroWebAPI: 


@staticmehtod 

def is hero(username): 
url - API URL.format(username) 
return webclient.get(url) 


多 数 情况 下 ， service 对 象 的 方法 是 无 状态 的 ， 即 ， 它 们 基于 函数 参数 不 使 用 任何 的 类 属性 
来 独自 执行 动作 。 因 此 ， 最 好 明确 地 把 它们 标记 为 静态 方法 (就 像 我 们 对 is hero 所 做 的 那 
样 ) 。 


可 以 考虑 把 业务 逻辑 和 域名 逻辑 从 模型 迁移 到 服务 对 象 中 去 。 这 样 ， 你 可 以 在 Django 应 用 的 
外 部 很 好 使 用 它们 。 

想象 一 下 ， 由 于 业务 的 原因 要 依据 某 些 用 户 的 名 字 把 这 些 要 成 为 超级 英雄 的 用 户 加 进 黑 名 
单 。 我 们 的 服务 对 象 稍微 改动 以 下 就 可 以 支持 这 个 功能 


class SuperHeroWebAPI: 


@staticmethod 

def is hero(username): 
blacklist = set(["syndrome", "kcka$$", "superfake"]) 
ulr - API URL.format(username) 
return username not in blacklist and webclient.get(url) 


理论 上 ， 服 务 对 象 自 包含 的 。 这 使 它们 不 用 建 模 一 一 即 数据 库 ， 也 可 以 多 于 测试 。 它 们 也 多 
于 复 用 。 


Django 中 ， ley 方式 执行 。 通 常 ， service 对 象 以 Celery 
任务 的 方式 执行 操作 。 这 样 的 任务 可 以 周期 性 地 运行 或 者 延迟 运行 


检索 模式 


本 节 包 含 处 理 模 型 属性 的 访问 ， 或 者 对 模型 执行 查询 。 


o 


模式 -属性 字段 


问题 : 模型 有 以 方法 实现 的 属性 。 可 是 ， 这 些 属 性 不 应 该 保存 到 数据 库 。 


“解决 方案 : 对 这 样 的 方法 使 用 属性 装饰 器 。 


= 


问题 详情 
模型 字段 存储 每 个 实例 的 属性 ， 比 如 名 ， 和 姓 ， 生 日 ， 等 等 。 它 们 存储 于 数据 库 之 中 。 可 
是 ， 我 们 也 需要 访问 某 些 派生 的 属性 ， 比 如 一 个 完整 的 名 字 和 年 龄 。 


它们 可 以 轻易 地 计算 数据 库 字 段 ， 因 此 它们 不 需要 单独 地 存储 。 在 某 些 情况 下 ， 它 们 可 以 成 
为 一 个 检查 所 提供 的 年 龄 ， 会 员 积分 ， 和 激活 状态 是 否 合格 的 条 件 语句 。 


简洁 明了 的 实现 这 个 方法 是 定义 比如 类 似 get age 这 样 函 数 : 


class BaseProfile(models.Model): 
birthdate = models.DateField() 


def get age(self): 
today - datetime.date.today() 
return (today.year - self.birthdate.year) - int( 
(today.month, today.day) « (self.birthdate.month, self.birthdate.day) 
) 


调用 profile.get age() 会 通过 计算 调整 过 的 月 和 日 期 所 在 的 那个 年 份 的 不 同 来 返回 用 户 的 年 
BE e 


不 过 ， 这 样 调用 profile.age 变 得 更 加 可 读 (和 Python 范 ) 。 
详解 


Python 类 可 以 使 用 property 装饰 器 把 函数 当 作 一 个 属性 来 使 用 。 这 样 ，Django 模 型 也 可 以 较 
好 地 利用 它 。 替 换 前 面 那个 例子 中 的 函数 : 


@property 
def age(self): 


现在 我 们 可 以 用 profile.age 来 访问 用 户 的 年 龄 。 注 意 ， 遂 数 的 名 称 要 尽 可 能 的 短 。 

属性 的 一 个 重大 缺陷 是 它 对 于 ORM 来 说 是 不 可 访问 的 ， 就 像 模 型 的 方法 那样 。 你 不 能 够 在 一 
个 Queryset 对 象 中 使 用 它 。 例 如 ， 这 么 做 是 无 效 的 ，`Profile.objects.exlude(age__It=18)。 
它 也 是 一 个 定义 一 个 属性 来 隐藏 类 内 部 细节 的 好 主意 。 这 也 正式 地 称 做 得 墨 式 耳 定 律 。 简 单 
地 说 ， 定 律 声明 你 应 该 只 访问 自己 的 直属 成 员 或 者 “ 仅 使 用 一 个 点 号 ”。 


例如 ， 最 好 是 定义 一 个 profile.birthyear 属性 ， 而 不 是 访问 profile.birthdate.year 。 这 
样 ， 它 有 助 于 你 隐藏 birthdate 字段 的 内 在 结构 。 


遵循 得 墨 忒 耳 定 律 ， 并 且 访 问 属 性 时 只 使 用 点 号 


该 定律 的 一 个 不 良 反 应 是 它 导致 在 模型 中 有 多 个 包装 器 属性 被 创建 。 这 使 模型 膨胀 并 让 
它们 变 得 难以 维护 。 利 用 定律 来 改进 你 的 模型 API|， 减 少 模型 间 的 耦合 nner 


缓存 特性 


每 次 我 们 调用 一 个 属性 时 ， 就 要 重新 计算 函数 。 如 果 计 算 的 代价 很 大 ， 我 们 就 想到 了 缓存 结 
果 。 因 此 ， 下 次 访问 属性 ， 我 们 就 拿 到 了 缓存 的 结果 。 


from django.utils.function import cached_property 
Haaa 
@cached_property 
def full drop 
H 代价 高 兄 的 操作 ， 比 如 ， 外 部 服务 调用 
return "[9) n. E ES firstname, self.lastname) 


缓存 的 值 会 作为 Python 实例 的 一 部 分 而 保存 。 只 要 实例 一 直 存 在 ， 就 会 得 到 同样 的 返回 值 。 


对 于 一 个 保护 性 机 制 ， 你 或 许 想 要 强制 执行 高 兄 代 价 操 作 以 确保 过 期 的 值 不 会 返回 。 如 此 情 
境 之 下 ， 设 置 一 个 cached=False 这 样 的 关键 字 参 数 能 够 阻止 返回 缓存 值 。 


问题 : 某 些 模 型 的 定义 的 查询 被 重复 地 访问 ， 这 彻 彻底 底 的 违反 了 DRY 原 则 。 


解决 方案 : 定义 自 定义 的 管理 器 以 给 常见 的 查询 一 个 更 有 意义 的 名 字 。 
问题 细节 


E n a objects 的 管理 器 。 调 用 objects.all() 会 返回 数据 
库 中 的 这 个 模型 的 所 有 条 目 。 ， 我们 只 对 所 有 条 目的 子 集 感 兴趣 。 


我 们 应 用 多 种 过 滤器 以 找 出 所 需 的 条 目 组 。 挑 选 它们 的 原则 常常 是 我 们 的 核心 业务 逻辑 。 例 
如 ， 我 们 发 现 使 用 下 面 的 代码 可 以 通过 public 访 问 文章 : 


public = Posts.objects.filter(privacy="public") 


这 个 标准 在 未 来 或 许 会 改变 。 我 们 或 许 也 想 要 检查 文章 是 否 标记 为 编辑 。 这 个 改变 或 许 如 
wh : 


public = Posts.objects.filter(privacy=POST_PRIVACY.Public, draft=Flase) 


DA RARE ELE ETE ATREA AALE o RAER o MREB VEN 
这 样 常见 地 查询 而 无 需 “ 自 我 重复 "。 


E 


详解 
Querysets 是 一 个 极其 有 用 的 抽象 概念 。 它们 仅 在 需要 时 进行 by YE S e E th » BEA 
法 (一 个 流畅 的 界面 ) 构建 更 长 的 Querysets 并 不 影响 性 能 。 


事实 上 ， 应 该 更 多 的 过 滤 会 使 结果 数据 集 缩减 。 这 样 做 通常 可 以 减少 结果 的 内 存 消耗 。 


模型 管理 器 是 一 个 模型 获取 自身 Queryset 对 象 的 便利 接口 。 换 和 句 话 来 讲 ， 它 们 有 助 于 你 使 用 
Django 的 ORM 访 问 潜在 的 数据 库 。 事 实 上 ， Queryset 对 象 上 管理 器 以 一 个 非常 简单 的 包装 
器 实现 。 

>>> Post.objects.filter(posted_by__username="a") 

[<Post:a: Hello World»* <Post:a: This is Private!>] 


>>> Post.objects.get_queryset().filter(posted_yb__username="a" ) 
[<Post:a: Hello World>, <Post:a: This is Private!>] 


默认 的 管理 器 由 Django 创 建 objects 有 多 种 方法 返回 Queryset ， 比 如 all ， filter 或 
者 exclude 。 可 是 ， 它 们 生成 一 个 到 数据 库 的 低级 API o 


ws Cop onu QUA MG hits ua a 
轻 影响 。 因 此 ， 你 能 够 在 更 高 级 的 抽象 概念 上 工作 ， 紧 密 地 模型 化 到 域名 。 


前 面 的 公共 文章 例子 可 以 轻松 地 转换 到 一 个 定制 的 管理 器 : 


# managers.py 
from django.db.models.query import Queryset 


class PostQuerySet(QuerySet): 
def public_posts(self): 
return self.filter(privacy="public") 


PostManager = PostQuerySet.as_manager 


这 是 一 个 在 Django 1.7 中 从 queryset 对 象 创建 定制 管理 器 的 捷径 。 不 像 前 面 的 其 他 方法 ， 这 
个 postManager 对 象 像 默认 的 objects 管理 器 一 样 是 链 式 的 。 


如 下 所 示 ， 使 用 我 们 的 定制 管理 器 替换 默认 的 objects 管理 器 也 是 可 行 的 : 


from .managers import PostManager 
class Post(Postable): 
objects = PostManager() 


这 样 做 ， 访 问 public_posts 相当 简单 : 


public = Post.objects.public_posts() 


因此 返回 值 是 一 个 Queryset ， 它 们 可 以 更 进一步 过 滤 : 


public_apology = Post.objects.public_posts().filter( 
message_startwith = "Sorry" 


) 


QuerySets 由 多 个 有 趣 的 属性 。 在 下 一 章 ， 我 们 可 以 看 看 某 些 带 有 合并 的 queryset 的 常见 地 
模式 。 


Querysets 的 组 合 动 作 


事实 上 ， 对 于 它们 的 名 字 ， Querysets 支持 多 组 操作 。 为 了 说 明 ， 考 虑 包含 用 户 对 象 的 两 
个 QuerySets 

>>> q1 = User.objects.filter(username_in["a", "b", "c"]) 

[<User:a>, <User:b>, <User:c>] 


>>> q2 = User.objects.filter(username_in["c", "d"]) 
[<User:c>, <User:d>] 


对 于 一 些 组 合 操作 可 以 执行 以 下 动作 : 





*Union* : 合并 ， 移 除 


Ha 


多 复 动作 。 使 用 `q1` | `q2 获得 [`<User: a», «User: b», «User: c», «User: d»'] 


*Intersection* : 找 出 公共 项 。 使 用 `q1` | `q2 .获得 [`<User: c>] 


*Difference* : 从 第 一 个 组 中 移 除 第 二 个 组 。 该 操作 并 不 按 逻 辑 来 。 改 用 `q1.exlude(pk in=q2) 获 得 («User: « 





同样 的 操作 我 们 也 可 以 用 o 对 象 来 完成 : 


from django.db.models import Q 


# Union 

>>> User.objects.filter(Q(username_in["a", "b", "c"]) | Q(username__in=["c", "d"])) 
[ «User: a», «User: b», «User: c», «User: d»'] 

# Intersection 

>>> User.objects.filter(Q(username_in["a", "b", "c"]) & Q(username__in=["c", "d"])) 
[xUser: c>] 

4 Difference 

>>> User.objects.filter(Q(username in-["a", "b", "c"]) & ~Q(username__in=["c", "d"]) 
[xUser: a», «User: b>] 


«| — OB 


注意 执行 动作 所 使 用 & (fe) 以 及 ~- (否定 ) 的 不 同 。 Q 对 象 是 非常 强大 的 ， 它 可 以 用 来 
构建 非常 复杂 的 查询 。 








可 是 ， set 虽 类 似 但 却 不 完美 。 querysets 不 像 数学 上 的 集合 ， 那 样 按照 顺序 来 。 因 此 ， 在 
这 一 方面 它们 更 接近 Python 的 列表 数据 结构 。 


链接 多 个 Querysets 


目前 为 止 ， 我 们 已 经 合并 了 属于 相同 基 类 的 同类 型 Querysets 。 可 是 ， 我 们 或 许 需 要 合并 来 
自 不 同 模型 的 Questsets ， 并 对 它们 执行 操作 。 


例如 ， 一 个 用 户 的 活动 时 间 表 包含 了 它们 自身 所 有 的 按照 反 向 时 间 顺 序 所 发 布 的 文章 和 评 
论 。 之 前 合并 的 Querysets 方法 是 不 会 起 作用 的 。 一 个 较为 天 申 的 做 法 是 把 它们 转换 到 列 
表 ， 连 接 并 排列 这 个 列表 : 

>>> recent = list(posts)+list(comments) 


>>> sorted(recent, key=lambda e: e.modified, reverse=True)[:3] 
[<Post: user: Posti», «Comment: user: Commenti», «Post: user: Post0>] 


不 幸 的 是 这 个 操作 已 经 对 情 性 的 QuerySets 对 象 求 值 了 两 个 列表 的 内 存 使 用 算 在 一 起 可 
能 很 大 内 存 开 销 。 另 外 ， 转 换 一 个 庞大 的 Querysets 到 列表 是 很 慢 很 慢 的 。 
一 个 更 好 的 解决 方案 是 使 用 迭代 器 减少 内 存 消 耗 。 如 下 ， 使 用 itertools.chain 方法 合并 多 


个 QuerySets 


>>> from itertools import chain 
>>> recent = chain(posts, comments) 
>>> sorted(recent, key=lambda e: e.modified, reverse=True)[:3] 


只 要 计算 QuerySets ， 连接 数据 的 开销 都 会 非常 搞 。 因 此， 重要 的 是 ， 尽 可 能 长 的 仅 有 的 不 
对 Querysets 求 值 的 操作 时 间 。 


提示 


尽量 延长 querysets 不 求 值 的 时 间 


迁移 
迁移 让 你 改变 模型 时 更 有 信心 。 说 的 Django 1.7， 迁 移 已 经 是 开发 流程 中 基本 的 易于 使 用 的 一 
部 

新 的 基本 流程 如 下 : 


1. 第 一 次 定义 模型 类 的 话 ， 你 需要 运行 : 


python manage.py makemigrations <app_label> 


2. 这 将 在 “app/migrations/ ` 文 件 夹 内 创建 迁移 脚本 。 
在 同样 的 (开发 ) 环境 中 运行 以 下 命令 : 


python manage.py migrate <app_label> 
3. 这 将 对 数据 库 应 用 模型 变更 。 有 时 候 ， 遇 到 的 问题 有 ， 处 理 默认 值 ， 重 命名 ， 等 等 。 
4. 普及 迁移 脚本 到 其 他 的 环境 。 通 常 ， 你 的 版 本 控制 工具 ， 例 如 ，Git， 会 小 心 处理 这 事 。 当 最 新 的 源 释 出 时 ， 新 的 迁 
5. 在 这 些 环 境 中 运行 下 面 的 命令 以 应 用 模型 的 改变 : 


python manage.py migarte <app_label> 


不 论 何 时 要 将 变更 应 用 到 模型 ， 请 重复 以 上 1-5 步 又 。 
Eee ee: 


如 果 你 在 命令 里 忽略 了 app 标 签 ，Django 会 在 每 一 个 app 中 发 现 未 应 用 的 变更 并 迁移 它们 。 








IN Django 开 发 的 基础 。 本 章 ， 我 们 学 习 了 使 用 模型 时 
多 个 常见 模式 。 每 个 例子 中 ， 我 们 都 见 到 了 建议 方案 的 作用 ， 以 及 多 种 折衷 方案 。 


这 下 一 章 ， 我 们 会 用 视图 和 URL 配 置 来 验证 所 遇 到 的 常见 设计 模式 。 
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1. 


Mi 比 V 和 C 更 大 


2.， 模 型 选取 
= 分 拆 model.py 到 多 个 文件 
3. 结构 化 模型 
m 模式 -规范 化 的 模型 
m 具体 问题 
m 答案 细节 
@ 第 一 个 规范 表单 
@ 第 二 个 规范 表单 
= Django 模型 
m 性 能 和 反 规 范 
a 我 们 应 该 一 直 遵守 规范 化 吗 ? 
m 模式 -模型 mixin 
m 具体 问题 
m 答案 细节 
a 信号 
= Admin 
m 多 账户 类 型 
a 模式 -服务 对 象 
m 具体 问题 
a 答案 细节 
4. 检索 模式 
m 模式 -属性 字段 
m 具体 问题 
a 答案 细节 
m AA 
a 模式 - 自 定义 模型 管理 
m 具体 问题 
m 答案 细节 
= 对 QuerySet 的 操作 
m 链接 多 个 QuerySet 


5. 迁移 
6， 总 结 
第 四 章 视图 和 URL 


章 
1. 来 自 顶 端的 视图 

m 让 视图 更 高 级 
.基于 类 的 通用 视图 


m 混合 的 顺序 


5. 视图 模式 
m 模式 -访问 控制 视图 
m 具体 问题 
m 详细 答案 
m 模式 -上 下 文 增强 器 
m 具体 问题 
m 详细 答案 
n 模式 -服务 
m 具体 问题 
m 详细 答案 
6. 设计 URL 
= URL# #7 
在 urls.py 中 发 了 什么 ? 
URL 模 式 语 法 
m Mnemonic — parents question pink action-figures 
名 字 和 命名 空间 
模式 顺序 
URL 模 式 风格 
2 分 部 门 存储 URL 
m RESTful URL 


d bE 


T. Di 
o PRE 模板 
= 理解 Django 的 模板 语言 特点 
= 变量 
a 属性 
n" 过 滤器 
a 标签 
设计 芹 学 -不 要 发 明 一 种 编程 语言 
m 规划 模板 
mo 支持 其 他 的 模板 语言 
= 使 用 Bootstrap 
m 可 是 ， 他 们 看 上 去 都 一 样 ! 
m 模式 -模板 继承 树 
m 具体 问题 
m 详细 答案 
m 模式 -激活 的 链接 
m 具体 问题 
m 详细 答案 


m 仅 使 用 模板 的 解决 方案 


" 
I 
e 
x: 
zx 
o 


a 


W c; 
o 第 六 章 Admin 接 口 
» 使 用 admin 接 口 
» 对 admin 使 用 加 强 的 模型 
a 不 是 每 一 个 人 都 应 该 称 为 admin 
» 自 定义 Admin 接 口 
n 改变 base 模 板 和 样式 表 
2 给 WYSIWG 编 辑 添加 一 个 富 文 本 编辑 器 
= admin 的 Bootstrap 主 题 
m 完成 变革 
a 保护 Admin 
m 模式 -特性 标识 
m 具体 问题 
m 详细 答案 


总 疆 


o 第 七 章 表单 
1. 表单 是 如 何 工作 的 
= Django 中 的 表单 
m 为 什么 数据 需要 清洁 ? 
2. 显示 表单 
m 时 间 变 得 很 脆弱 
理解 CSRF 
使 用 基于 类 的 表单 处 理 
5， 表 单 模式 
m 模式 -动态 表单 生成 
m 具体 问题 
m 详细 答案 
m 模式 -基于 用 户 的 表单 
m 具体 问题 
m 详细 答案 
m 模式 -一 个 视图 的 多 个 表单 行为 
m 具体 问题 
m 详细 答案 
m 对 单独 的 行为 使 用 单独 的 视图 
m 单独 的 行为 使 用 相同 的 视图 
» 模式 -CRUD 视 图 
m 具体 问题 


m 详细 答案 


kw 


6. 
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o PAE 处 理 早期 代码 


1. 


a Aa W N 


找到 Django 版 本 
m 激活 虚拟 环境 


. 文件 放 在 哪里 ?这 可 不 是 PHP 
.从 urls.py 开 始 

.跳跃 的 代码 

.理解 代码 基础 


a 绘制 宏伟 蓝图 


， 增 量 改 进 还 是 完全 重 写 ? 
， 做 出 任何 改变 之 前 都 要 写 测试 


m VRS MIA 8. 早 期 数据 库 9. 总 结 


o BILE 测试 和 调试 


o 


1. 
2. 
3. 


为 什么 要 写 测试 ? 
测试 驱动 的 开发 

写 一 个 测试 的 案例 

a 断言 方法 

wm 写 出 更 好 的 测试 案例 
建 模 


.模式 -测试 装置 和 工厂 


m 具体 问题 


m 详细 答案 


， 学 习 更 多 的 测试 知识 
.调试 


» _ Django 的 调试 页 面 
m 一 个 更 好 的 调试 页 面 


. print% 2k 

. BA 
.Diango 调 试 工具 条 
.Python 的 调试 器 pdb 
.其 他 的 调试 器 
.调试 Django 模 板 

. 总结 


第 十 章 安全 


1. 


跨 站 脚本 (XSS) 
m 为 什么 你 的 cookies 如 何 有 利用 价值 ? 
» Django 是 如 何 帮 助 你 的 
a 在 什么 地 方 Django 也 帮 不 上 你 
a 跨 站 请 求 伪 造 (CSRF) 
» Django 是 如 何 帮助 你 的 


a 在 什么 地 方 Django 也 帮 不 上 你 
=» SQL 注入 

» Django 是 如 何 帮 助 你 的 

a 在 什么 地 方 Django 也 帮 不 上 你 


m 点 击 动 持 
» Django 是 如 何 帮 助 你 的 
» Shell 注 入 


» Django 是 如 何 帮 助 你 的 
攻击 方法 的 列表 还 在 增长 中 
2. 一 张 便捷 的 安全 检查 清单 
3， 总 结 


心志 


o 第 十 一 章 产品 预 发 布 
1. 产品 环境 
m 选择 一 个 Web 栈 
m 一 个 栈 的 组 件 
2. 托管 
a FERRI 
m 虚拟 私有 服务 
m 其 他 的 托管 方法 
3. BALA 
= Fabric 
m 典型 的 几 种 部 署 步骤 
a 配置 的 管理 


4. 监测 
5， 性 能 
w 前 端 性 能 
m 后 端 性 能 
m 模板 
@ 数据 库 
a 缓存 
a 缓存 会 话 后 端 
n 缓存 框架 
m 缓存 模式 
6， 总 结 


o 目录 -A Python2 VS Python 3 
不 过 我 依 昌 使 用 Python2.7 ! 
m Python 3 
=» Python 3 for Djangonauts 
m 改变 所 有 的 unicode 方法 到 ster AR 
wm 所 有 的 类 都 应 该 继承 自 object 类 


= 调用 Super() 更 简单 
m 必须 更 明确 地 相对 导入 
= HttpRequest and HttpResponse have str and bytes types 
a 异常 语法 的 改变 和 提高 
m 重组 标准 库 
m 新 东西 
a 使 用 Pyvenv 和 Pip 
m 其 他 的 改变 
= 更 多 内 容 


第 一 章 Django 与 模式 
在 这 一 章 ， 我 们 讨论 以 下 话题 : 


我 们 为 什么 选择 Django? 
Django 是 工作 原理 

什么 是 模式 ? 

常见 的 模式 合集 
Django 中 的 模式 


我 们 为 什么 选择 Django ? 


每 个 Web 应 用 都 不 尽 相 同 ， 就 像 一 件 手工 制作 的 家 具 一 样 。 你 几乎 会 很 少 发 现 大 批量 的 生成 能 
够 完美 地 达到 你 的 需求 。 即 使 你 从 一 个 基本 需求 开始 ， 比 如 一 个 博客 或 者 一 个 社交 网 络 ， 你 
都 需要 缓慢 地 开发 ， 


这 就 是 类 似 Django 或 者 Rails 的 web 框 架 非常 流行 的 原因 。 框 架 加 速 了 开发 ， 而 且 它 带 有 很 多 
练 好 的 经 过 实践 的 内 容 。 


Python 可 能 比 其 他 流行 的 编程 语言 具有 更 多 的 web 框 架 


开 箱 即 用 的 admin 接 口 ， 它 是 Django 才 有 的 独一无二 的 特点 ， 早 些 时 候 ， 特 别 
测试 方面 它 大 有 神 益 。 而 Django 的 开发 文档 作为 一 个 出 色 的 开源 项 目 早已 是 备 受 赞誉 


最 后 ，Django 在 多 个 高 流量 的 网 站 中 历经 实战 的 考验 。 它 对 于 常见 的 攻击 比如 跨 站 脚本 和 跨 
站 请 求 攻击 有 着 异常 敏锐 观察 。 


尽管 ， 在 理论 上 ， 可 能 对 于 所 有 类 型 的 网 站 Django 不 是 最 佳 选 择 ， 你 可 以 是 使 用 Django 构 建 
任何 类 型 的 网 站 。 例 如 ， 要 构建 一 个 基于 web 聊 天 的 实时 接口 ， 或 许 你 要 使 用 Tornado， 但 是 
web 引 用 剩 下 的 部 分 你 可 以 仍旧 使 用 Django 来 完成 。 对 于 开发 你 要 学 会 选择 正确 的 工具 。 


某 些 内 建 的 特性 ， 比 如 admin 接 口 ， 如 果 你 使 用 过 其 他 的 web 框 架 或 许 让 你 听 上 去 感觉 有 点 怪 
怪 的 。 为 了 Django 的 设计 ， 就 让 我 们 找 出 它 是 如 何 问世 的 。 


Django 的 历史 


When you look at the Pyramids of Egypt, you would think that such a simple and minimal 
design must have been quite obvious. In truth, they are products of 4,000 years of 
architectural evolution. Step Pyramids, the initial (and clunky) design, had six rectangular 
blocks of decreasing size. It took several iterations of architectural and engineering 
improvements until the modern, glazing, and long-lasting limestone structures were 
invented. 


当 你 看 到 埃及 金字 塔 的 历史 时 ， 你 会 很 明显 地 认为 它 是 一 个 简单 、 小 规模 的 设计 。 事 实 上 ， 
埃及 人 的 作品 是 经 历 了 四 千年 建筑 的 进化 。 当 你 走 进 金 字 塔 时 就 能 够 发 现 它 的 原始 设计 ( 非 
常 厚重 ) ， 拥 有 六 个 矩形 的 阶梯 式 递减 的 大 石 块 。 


Looking at Django you might get a similar feeling. So, elegantly built, it must have been 
awlessly conceived. n the contrary, it was the result of rewrites and rapid iterations in one 
of the most high-pressure environments imaginable 一 a newsroom! 


再 回头 来 看 看 Django 你 也 会 有 类 似 的 感觉 。 因 此 ， 如 果 要 简洁 的 构建 它 ， 必 须 经 过 无 知 无 展 
的 设想 。 


In the fall of 2003, two programmers, Adrian Holovaty and Simon Willison, working at the 
Lawrence Journal-World newspaper, were working on creating several local news websites 
in Kansas. These sites, including LJWorld.com, Lawrence.com, and KUsports.com—like 
most news sites were not just content-driven portals chock- full of text, photos, and videos, 
but they also constantly tried to serve the needs of the local Lawrence community with 
applications, such as a local business directory, events calendar, classifieds, and so on. 


一 个 框架 的 诞生 


This, of course, meant lots of work for Simon, Adrian, and later Jacob Kaplan Moss who had 
joined their team; with very short deadlines, sometimes with only a few hours' notice. Since it 
was the early days of web development in Python, they had to write web applications mostly 
from scratch. So, to save precious time, they gradually refactored out the common modules 
and tools into something called "The CMS." 


Eventually, the content management parts were spun off into a separate project called the 
Ellington CMS, which went on to become a successful commercial CMS product. The rest of 
"The CMS" was a neat underlying framework that was general enough to be used to build 
web applications of any kind. 


By July 2005, this web development framework was released as Django (pronounced Jang- 
Oh) under an open source Berkeley Software Distribution (BSD) license. It was named after 
the legendary jazz guitarist Django Reinhardt. And the rest, as they say, is history. 


移 除 魔法 


Due to its humble origins as an internal tool, Django had a lot of Lawrence 
ournalWorldspecific oddities. To ake Django truly general purpose, an effort dubbed 
"Removing the Lawrence" was already underway. 


However, the ost significant refactoring effort that Django developers had to undertake was 
called "Removing the Magic." This ambitious project involved cleaning up all the warts 
Django had accumulated over the years, including a lot of magic (an informal term for 
implicit features) and replacing them with a more natural and explicit Pythonic code. For 
example, the model classes used to be imported from a magic module called 
django.models.*, rather than directly importing them from the models.py odule they were 
defined in. 


At that time, Django had about a hundred thousand lines of code, and it was a significant 
rewrite of the PI. n May , , these changes, alost the sie of a small book, were 

integrated into Django's development version trunk and released as Django release .. 
This was a significant step toward the Django . 


Django € 4 AT 3 $$ 


Every year, conferences called DjangoCons are held across the world for Django developers 
to meet and interact with each other. They have an adorable tradition of giving a semi- 
humorous keynote on "why Django sucks." This could be a member of the Django 
community, or someone who works on competing web frameworks or just any notable 
personality. 


Over the years, it is amazing how Django developers took these criticisms positively and 
mitigated them in subsequent releases. Here is a short summary of the improvements 
corresponding to what once used to be a shortcoming in Django and the release they were 
resolved in: 


e New form-handling library (Django 0.96) 

e Decoupling admin from models (Django 1.0) 
e Multiple database support (Django 1.2) 

e Managing static files better Django . 

e Better time zone support (Django 1.4) 

e Customizable user model (Django 1.5) 

e Better transaction handling (Django 1.6) 

e Built-in database migrations (Django 1.7) 


Django 是 如 何 工作 的 ? 


要 丨 正 的 欣赏 Django， 你 需要 撤 开 表象 来 看 本 质 。 它 启发 你 得 同时 也 让 会 让 你 不 知 所 措 。 如 
果 你 已 经 比较 了 解 它 ， 你 可 以 选择 跳 过 这 一 节 。 
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下 图 : 在 Django 应 用 中 一 个 典型 的 web 请 求 是 如 何 被 处 理 的 。 
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前 面 的 图 片 展示 了 从 一 个 访客 的 浏览 器 到 Django 应 用 并 返回 的 一 个 web 请 求 的 简单 历程 。 如 
下 是 数字 标识 的 路 径 : 


.浏览 器 发 送 请 求 〈 基 本 上 是 字 节 类 型 的 字符 串 ) 到 web 服 务 器 。 


2. web 服 务 器 (比如 ，Nginx) 把 这 个 请 求 转交 到 一 个 WSGI (比如 ，UWSGI) ， 或 者 直接 地 文件 系统 能 够 取出 
一 个 文件 (比如 ， 一 个 CSS 文 件 ) 。 


3. 不 像 Web 服 务 器 那样 ，WSGI 服 务 器 可 以 直接 运行 Python 应 用 。 请 求生 成 一 个 被 称 为 environ 的 Ptyhon 字 典 ， 
而 且 ， 可 以 选择 传递 过 去 几 个 中 间 件 的 层 ， 最 终 ， 达 到 Django 应 用 。 


4. URLconf 中 含有 属于 应 用 的 Urls .py 选择 一 个 视图 处 理 基 于 请 求 的 URL 的 那个 请 求 ， 这 个 请 求 就 已 经 变 成 了 
HttpRequest- 一 一 个 Python 字典 对 象 。 


5. 被 选择 的 那个 视图 通常 要 做 下 面 所 列 出 的 一 件 或 者 更 多 件 事情 : 
通过 模型 与 数据 库 对 话 。 
使 用 模板 泻 染 HTML 或 者 任何 格式 化 过 的 响应 。 
返回 一 个 纯 文本 响应 (不 被 显示 的 ) 。 
抛 出 一 个 异常 。 
6. HttpResponse 对 象 离开 Django 后 ， 被 泻 染 为 一 个 字符 串 。 


7， 在 浏览 器 见 到 一 个 美化 的 ， 泻 染 后 的 Web 页 面 。 
虽然 菜 些 细节 被 省 略 掉 ， 这 个 解释 应 该 有 助 于 欣赏 Django 的 高 级 架构 。 它 也 展示 了 关键 的 组 


件 所 扮演 的 角色 ， 比 如 模型 ， 视 图 ， 和 模板 。Dijango 的 很 多 组 件 都 基于 这 几 个 广为人知 设计 
模式 。 


什么 是 模式 ? 


What is coon between the words Blueprint, caffolding, and Maintenance? 

These software development terms have been borrowed from the world of building 
construction and architecture. However, one of the ost inuential ters coes from a 

treatise on architecture and urban planning written in 1977 by the leading Austrian architect 
Christopher Alexander and his team consisting of Murray Silverstein, Sara Ishikawa, and 
several others. 


The term "Pattern" came in vogue after their seminal work, A Pattern Language: Towns, 
Buildings, Construction volue in a fivebook series based on the astonishing insight 

that users know about their buildings more than any architect ever could. A pattern refers to 
an everyday problem and its proposed but time-tested solution. 


In the book, Christopher Alexander states that "Each pattern describes a problem, which 
occurs over and over again in our environment, and then describes the core of the solution 
to that problem in such a way that you can use this solution a million times over, without ever 
doing it the same way twice." 


For example, the Wings Of Light pattern describes how people prefer buildings with more 
natural lighting and suggests arranging the building so that it is composed of wings. These 
wings should be long and narrow, never more than 25 feet wide. Next time you enjoy a stroll 
through the long well-lit corridors of an old university, be grateful to this pattern. 


Their book contained 253 such practical patterns, from the design of a room to the design of 
entire cities. Most importantly, each of these patterns gave a name to an abstract problem 
and together formed a pattern language. 


Reeber when you first cae across the word déja vu? You probably thought "Wow, | 

never knew that there was a word for that experience." Similarly, architects were not only 
able to identify patterns in their environent but could also, finally, name them in a way that 
their peers could understand. 


In the world of software, the term design pattern refers to a general repeatable solution to a 
commonly occurring problem in software design. It is a formalization of best practices that a 
developer can use. Like in the world of architecture, the pattern language has proven to be 
extremely helpful to communicate a certain way of solving a design problem to other 
programmers. 


There are several collections of design patterns but some have been considerably ore 
inuential than the others. 


四 人 组 模式 


One of the earliest efforts to study and document design patterns was a book titled Design 
Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, 
Ralph Johnson, and John Vlissides, who later became known as the Gang of Four (GoF ). 
This book is so inuential that any consider the design patterns in the book as 

fundamental to software engineering itself. 


In reality, the patterns were written primarily for object-oriented programming languages, and 
it had code examples in C++ and Smalltalk. As we will see shortly, many of these patterns 
might not be even required in other programming languages with better higher-order 
abstractions such as Python. 


The patterns have been broadly classified by their type as follows 


e Creational Patterns: These include Abstract Factory, Builder Pattern, Factory Method, 
Prototype Pattern, and Singleton Pattern 

e Structural Patterns: These include Adapter Pattern, Bridge Pattern, Composite Pattern, 
Decorator Pattern, Facade Pattern, Flyweight Pattern, and Proxy Pattern 

e Behavioral Patterns: These include Chain of Responsibility, Command Pattern, 
Interpreter Pattern, Iterator Pattern, Mediator Pattern, Memento Pattern, Observer 
Pattern, State Pattern, Strategy Pattern, Template Pattern, and Visitor Pattern 


While a detailed explanation of each pattern would be beyond the scope of this book, it 
would be interesting to identify some of these patterns in Django itself: 


Django 中 的 模式 与 此 对 比 : 


2g 3E 
uu Django 组 件 解释 
命令 模式 HttpRequest 把 一 个 request 封 装 进 一 个 对 象 
观察 者 模 Si 一 个 对 象 改 变 状 态 时 ， 它 的 所 有 侦 听 器 都 被 通知 并 自动 更 
E ignals E 
X 新 
类 的 视 A Lar a T. 
Kuga ATASA 一 个 算法 的 步骤 可 以 不 用 改变 算法 结构 来 重新 定义 子 类 


而 这 些 模式 是 对 于 学 习 Django 内 部 的 人 来 说 构造 最 有 趣 的 ，Dijango 下 面 的 模式 可 以 再 次 分 类 
一 这 也 是 个 常见 的 问题 。 


Django% MVC 3 ? 


Model-View-Controller (MVC) is an architectural pattern invented by Xerox PARC in the 70s. 
Being the framework used to build user interfaces in Smalltalk, it gets an early mention in the 
GoF book. 


Today, MVC is a very popular pattern in web application frameworks. Beginners often ask 
the questionis Django an M fraework? 


The answer is both yes and no. The MVC pattern advocates the decoupling of the 
presentation layer from the application logic. For instance, while designing an online game 
website API, you might present a game's high scores table as an HTML, ML, or 
coaseparated file. However, its underlying odel class would be designed 

independent of how the data would be finally presented. 


MVC is very rigid about what models, views, and controllers do. However, Django takes a 
much more practical view to web applications. Due to the nature of the HTTP protocol, each 
request for a web page is independent of any other request. Django's framework is designed 
like a pipeline to process each request and prepare a response. 


Django calls this the Model-Template-View (MTV) architecture. There is separation of 
concerns between the database interfacing classes (Model), request-processing classes 
iew, and a teplating language for the final presentation Teplate. 


If you compare this with the classic MVC—"Model" is comparable to Django's Models, 
"View" is usually Django's Templates, and "Controller" is the framework itself that processes 
an incoming HTTP request and routes it to the correct view function. 


If this has not confused you enough, Django prefers to name the callback function to handle 
each URL a "view" function. This is, unfortunately, not related to the MVC pattern's idea of a 
View. 

MVC 对 于 模型 ， 视 图 ， 和 控制 该 做 什么 设 定 的 非常 严格 。 然 而 ， 到 web 应 用 Django 采 取 的 是 
更 实用 的 视图 。 要 处 理 原生 的 HTTP 协 议 ， 每 个 到 web 页 面 的 请 求 独立 于 其 他 的 请 求 。Django 
的 框架 设计 的 像 一 个 管道 处 理 每 个 请 求 ， 准 备 好 响应 。 

Django 称 之 为 模型 -模板 -视图 (MTV) 架构 。 数 据 库 接口 类 (模型) 和 请求 处 理 类 ( 视 

E) ， 以 及 最 终 表 现 的 模板 语言 之 间 有 着 独立 关系 。 


如 果 你 将 它 于 经 典 的 MVC 比 较 ，“ 模 型 "可 以 通 Django 的 模型 比较 ，“ 视 图 ” 
要 是 这 些 都 还 不 足以 让 你 感到 迷惑 ，Django 倾 向 于 选择 命名 回调 有 函数 处 理 每 个 URL 的 “视图 " 函 
数 。 即 ， 一 个 没有 MVC 视 图 概念 的 视图 。 


福 勒 模式 


In 2002, Martin Fowler wrote Patterns of Enterprise Application Architecture, which 
described 40 or so patterns he often encountered while building enterprise applications. 


Unlike the GoF book, which described design patterns, Fowlers book was about 
architectural patterns. Hence, they describe patterns at a much higher level of abstraction 
and are largely programming language agnostic. Fowlers patterns are organized as follows: 


* Domain Logic Patterns: These include Domain Model, Transaction Script, Service Layer , 
and Table Module * Data Source Architectural Patterns: These include Row Data Gateway, 
Table Data Gateway, Data Mapper, and Active Record * Object-Relational Behavioral 
Patterns: These include Identity Map, Unit of Work, and Lazy Load * Object-Relational 
Structural Patterns: These include Foreign Key Mapping, Mapping, Dependent Mapping, 
Association Table Mapping, Identity Field, Serialized LOB, Embedded Value, Inheritance 
Mappers, Single Table Inheritance, Concrete Table Inheritance, and Class Table Inheritance 
* Object-Relational Metadata Mapping Patterns: These include Query Object, Metadata 
Mapping, and Repository * Web Presentation Patterns: These include Page Controller, Front 
Controller, Model View Controller, Transform View, Template View, Application Controller, 
and Two-Step View * Distribution Patterns: These include Data Transfer Object and Remote 
Facade * Offline Concurrency Patterns: These include Coarse Grained Lock, Implicit Lock, 
Optimistic fine Lock, and Pessiistic fine Lock * Session State Patterns: These 

include Database Session State, Client Session State, and Server Session State * Base 
Patterns: These include Mapper, Gateway, Layer Supertype, Registry, Value Object, 
Separated Interface, Money, Plugin, Special Case, Service Stub, and Record Set 


Almost all of these patterns would be useful to know while architecting a Django application. 
In fact, Fowler's website at http://martinfowler.com/eaaCatalog/ has an excellent catalog of 
these patterns. | highly recommend that you check them out. 


Django also implements a number of these patterns. The following table lists a few of them: 


Django 中 的 模式 与 此 对 比 : 


四 人 组 模式 Django 组 件 解释 
活动 记录 Django 模 型 封装 数据 库 访 问 ， 对 数据 添加 域名 逻辑 
类 表 继 承 模型 继承 继承 中 的 每 个 实体 都 映射 到 一 个 独立 的 表 
标识 自动 ld 字段 在 一 个 对 象 中 保存 一 个 数据 库 ID 字 段 以 维护 标识 
模板 视图 Django 模 板 1& FI HTML 85 P d AE X, 237€ 4e 8S] HTML. 


还 有 更 多 的 模式 ? 


Yes, of course. Patterns are discovered all the tie. Like living beings, soe mutate and 
form new patterns: take, for instance, MVC variants such as Model-view-presenter (MVP), 
Hierarchical model-view-controller (HMVC), or Model View ViewModel (MVVM ). 


Patterns also evolve with tie as better solutions to known probles are identified. For 
example, Singleton pattern was once considered to be a design pattern but now is 
considered to be an Anti-pattern due to the shared state it introduces, similar to using global 
variables. An Anti-pattern can be defined as coonly reinvented but a bad solution to a 
problem. 


Some of the other well-known books which catalog patterns are Pattern-Oriented Software 
Architecture (known as POSA) by Buschmann, Meunier, Rohnert, Sommerlad, and Sta; 
Enterprise Integration Patterns by Hohpe and Woolf; and The Design of Sites: Patterns, 
Principles, and Processes for Crafting a Customer-Centered Web Experience by Duyne, 
Landay, and Hong. 


本 书 中 模式 


This book will cover Djangospecific design and architecture patterns, which would be 
useful to a Django developer. The upcoming sections will describe how each pattern will be 
presented. 


Pattern name The heading is the pattern name. If it is a well-known pattern, the commonly 
used name is used; otherwise, a terse, self-descriptive name has been chosen. Names are 
important, as they help in building the pattern vocabulary. All patterns will have the following 
parts: 

Problem: This briey entions the proble. 


Solution: This summarizes the proposed solution(s). 


Problem Details: This elaborates the context of the problem and possibly gives an example. 
Solution Details: This explains the solution(s) in general terms and provides a sample 
Django implementation. 
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每 个 模式 是 如 何 实现 的 。 


模式 名 称 标题 是 模式 名 称 。 如 果 它 是 知名 的 模式 ， 常 用 的 名 字 被 使 用 ; 和 否则， 简洁 的 ， 自 描 
述 的 名 称 被 选择 。 名 称 非 常 重要 ， 它 们 有 助 于 构建 模式 词汇 。 所 有 的 模式 都 有 以 下 部 分 
鉴 审 模式 

Despite their near universal usage, Patterns have their share of criticism too. The most 
common arguments against them are as follows: 

尽管 它们 近乎 于 通用 ， 模 式 共享 也 有 它们 的 审 鉴 共享 。 它 们 的 最 常见 参数 如 下 : 


e Patterns compensate for the missing language features: Peter Norvig found that 16 of 


the 23 patterns in Design Patterns were 'invisible or simpler in Lisp. Considering 
Python's introspective facilities and firstclass functions, this ight as well be the case 
for Python too. 

e Patterns repeat best practices: Many patterns are essentially formalizations of best 
practices such as separation of concerns and could seem redundant. 

e Patterns can lead to over-engineering: Implementing the pattern might be less efficient 
and excessive copared to a sipler solution. 


如 何 使 用 模式 


While some of the previous criticisms are quite valid, they are based on how patterns are 
misused. Here is some advice that can help you understand how best to use design 
patterns: 


e Don't implement a pattern if your language supports a direct solution 
e Don't try to retrofit everything in ters of patterns 

e 

e Use a pattern only if it is the most elegant solution in your context 

© 在 开发 环境 中 且 仅 当 解 决 方法 为 最 简练 时 使 用 模式 

e Don't be afraid to create new patterns 

e 不 要 害怕 创建 新 模式 


最 佳 实践 


In addition to design patterns, there might be a recommended approach to solving a 
problem. In Django, as with Python, there might be several ways to solve a problem but 
one idiomatic approach among those. 

除了 设计 模式 之 外 ， 还 是 存在 其 他 推荐 的 方法 来 解决 一 个 问题 。 在 Django 中 ， 因 为 使 用 
的 语言 就 是 Python， 所 以 我 们 就 有 


Generally, the Python community uses the term 'Pythonic' to describe a piece of idiomatic 
code. It typically refers to the principles laid out in 'The Zen of Python'. Written like a poem, it 
is extremely useful to describe such a vague concept. 

通常 来 说 ，Python 社 区 使 用 术语 “Python 范 儿 ?来 描述 一 段 编写 手法 地 道 的 代码 。 我 们 通常 参 
照 “Python 之 祥 ? 中 出 现 的 原则 。 就 像 写 诗歌 一 样 ， 它 在 描述 一 个 模糊 的 概念 时 及 其 有 用 。 


Try entering import this in a Python prompt to view 'The Zen of Python’. 


Furthermore, Django developers have crisply documented their design philosophies while 
designing the framework at https://docs.djangoproject.com/en/dev/ misc/design- 
philosophies/. 


While the document describes the thought process behind how Django was designed, it is 
also useful for developers using Django to build applications. Certain principles such as 
Don't Repeat Yourself (DRY), loose coupling, and tight cohesion can help you write more 
maintainable and idiomatic Django applications. 


Django or Python best practices suggested by this book would be formatted in the following 
manner: 


E 


最 佳 实践 : 


在 settings.py 中 使 用 BASE_DIR， 避 免 硬 编码 目录 名 称 。 


In this chapter, we looked at why people choose Django over other web frameworks, its 
interesting history, and how it works. We also examined design patterns, popular pattern 
collections, and best practices. 


本 章 ， 我 们 浏览 了 为 什么 人 们 选择 Django 而 不 是 其 他 的 Web 框 架 ， 以 及 它 的 发 展 史 ， 和 
Django 的 工作 原理 。 我 们 也 验证 了 设计 模式 ， 流 行 的 模式 集合 ， 以 及 最 佳 实践 。 
In the next chapter, we will take a look at the first few steps in the beginning of a Django 


project such as gathering requirements, creating mockups, and setting up the project. 


在 下 一 章 ， 我 们 会 学 习 Django 项 目 中 开始 的 头 几 个 步骤 ， 比 如 获取 请 求 ， 模 型 建 模 ， 以 及 项 
目 配 置 。 
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第 二 章 应 用 模式 
本 章 ， 我 们 将 学 习 以 下 内 容 : 


e 获取 请 求 

e 创建 一 个 概念 文档 

e 如 何 将 一 个 项 目 分 为 多 个 app 

e 是 重新 写 一 个 新 的 app 还 是 使 用 已 有 的 
e 开始 一 个 项 目 之 前 的 最 佳 实践 

。 为 什 是 Python3? 

e 局 动 SuperBook 项 目 


很 多 的 开发 新 手 从 依照 正确 方法 来 写 代 码 开 始 ， 完 成 一 个 新 的 项 目 。 而 更 多 的 人 经 常 被 引 到 
着 误 的 假想 ， 未 被 使 用 的 功能 ， 并 且 浪 费 掉 很 多 时 间 。 花 些 时 间 在 你 的 客户 身上 ， 来 理解 一 
个 项 目 中 的 核心 请 求 事件 ， 即 使 很 短 的 时 间 也 能 产生 惊人 的 效果 。 管 理 请 求 是 一 个 值得 学 习 
的 关键 知识 点 。 


+- ` ` 
如 何 获取 请 求 
创新 不 关乎 肯定 一 切 ， 而 是 关乎 对 所 有 重要 的 特性 说 不 ---Steve Jobs 


我 通过 与 客户 耗 去 数 天 来 仔细 地 的 倾听 他 们 的 需求 ， 以 及 合理 的 期 望 值 ， 拯救 了 好 几 个 注定 
失败 的 项 目 。 除 了 纸 (或 者 他 们 的 数字 设备 ) 和 一 支 笔 之 外 什么 也 没 用 ， 处 理 过 程 极其 简单 
但 是 却 很 有 效 。 这 里 是 一 些 获取 请 求 的 关键 地 方 : 


1. 直接 和 应 用 的 所 有 者 沟通 即使 他 们 没有 技术 背景 。 

2. 确保 你 完整 的 倾听 他 们 的 需求 并 提醒 他 们 。 

3. 不 要 使 用 /模型 "这 一 类 的 技术 术语 。 保 证 用 语 简单 ， 使 用 终端 用 户 能 理解 的 术语 比如 4 用 户 账户 ”。 

4 .合理 的 期 望 值 。 如 果 某 件 事情 在 技术 行 不 可 行 ， 或 者 很 难 实现 ， 要 保证 你 以 正确 的 方法 告知 他 们 。 

5. 描 述 的 尽 可 能 具象 。 在 大 自然 中 人 类 是 依靠 视觉 。 网 站 更 是 如 此 。 使 用 粗 线条 和 图 形 表 。 不 需要 多 人 么 的 完美 。 
6 .分 解 处 理 流程 ， 比 如 用 户 注 册 。 任 何 多 步骤 的 功能 都 需要 以 用 箭头 连接 的 方 框 画 出 。 

7. 最 后 ， 解 决 用 户 叙述 表格 中 的 特性 ， 

8 .扮演 一 个 活动 的 角色 

9 .在 融合 新 特性 上 要 非常 ， 非 常 地 保守 。 

19 .开会 ， 和 大 家 分 享 你 的 笔记 以 避免 误解 。 


第 一 个 会 议会 比较 长 (可 能 是 一 整个 工作 日 ， 或 者 好 几 个 小 时 ) 。 之 后 ， 当 这 些 会 议 的 沟通 
变 的 顺畅 时 ， 你 可 以 将 它们 削减 到 30 分 钟 或 者 一 个 小 时 。 
所 有 的 这 一 切 的 结果 会 是 写 了 满 满 的 一 整 页 ， 以 及 好 几 张 的 乱糟糟 的 草图 。 


在 本 书 ， 我 们 已 经 着 手 建构 我 们 自己 的 一 个 为 超级 英雄 而 构建 的 称 做 SuperBook 的 社会 网 
络 。Asimple sketch based off our discussions with a bunch of randomly selected 
superheroes is shown as follows: 


Django 设计 模式 与 最 佳 实践 


Super Book | Hoa Y | Super Book 





按照 响应 式 设 计 的 SuperBook 网 站 草图 。 桌 面 〈 左 边 ) 和 手机 (右边 ) 的 效果 如 上 . 


你 是 一 个 会 讲 故事 的 人 吗 ? 


AR A 


Ek 


& 5 04] A AI? 这 是 一 个 解释 使 用 这 个 网 站 是 做 何 感 觉 的 简易 文档 。 


1 
+e 
\ 


注释 

SuperBook 的 概念 下 面 的 访问 记录 是 在 未 来 我 们 的 网 站 SuperBook 运 营 之 后 所 做 的 整 
8 e 

注释 

SuperBook 的 理念 下 面 的 是 采访 是 在 未 来 我 们 的 网 站 SuperBook 网 站 运行 起 来 之 后 的 记 
录 。 一 个 半 小 时 的 用 户 测试 在 采访 之 前 就 做 过 了 。 


请 你 作 下 自我 介绍 俺 叫 阿 克 苏 。 俺 是 一 个 生活 在 纽 市 中 心 的 灰 松 鼠 。 不 过 呢 ， 大 家 都 叫 
fe p BE o AEH EIS EAB RB > Meet Aik HEY Ho HIATT > REG 
KA DRABS > Ashe ABT RVI © 


ERE > HER DAE ARA RILERM RG o RAHM RRR RHEKR 
ARAB Fo 38 "RI o HSE RL Ay JUS SP PTE RAB REL o HEU LAB TY VUE TETT IS SE 
下 去 。 俺 也 曾 酒馆 ， 电 影院 ， 游 乐园 ， 还 有 好 多 地 方 把 歌唱 。 俺 看 唱片 的 时 候 ， 成 别 认 


好 吧 ， 阿 康 。 你 为 什么 被 挑选 为 测试 用 户 ， 你 知道 为 什么 吗 ? 


可 能 吧 ， 因 为 俺 是 纽约 大 明星 里 最 少 知道 超级 英雄 的 人 。 傣 猜 啊 ， 这 人 类 啊 都 笑话 俺 这 
只 可 以 用 革 果 电脑 的 松鼠 。 和 补充 一 名 ， 伤 可 是 一 只 非常 有 耐心 的 松鼠 © 


就 你 所 见 到 的 ， 你 来 说 一 说 你 所 认识 的 SuperBook 是 个 什么 样子 


第 二 章 app 的 模式 
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Django 设计 模式 与 最 佳 实践 


Actually, in my early days, | was a bit of a kleptomaniac. | am allergic to nuts, you know. 
Other bros have it easy. They can just live off any park. | had to improvise—cafes, 
movie halls, amusement parks, and so on. | read labels very carefully too. 


Ok, Acorn. Why do you think you were chosen for the user testing? 


Probably, because | was featured in a Y tar special on lesserknown superheroes. | 
guess people find it ausing that a squirrel can use a MacBook (Interviewer: this 
interview was conducted over chat). Plus, | have the attention span of a squirrel. 


Based on what you saw, what is your opinion about SuperBook? 


| think it is a fantastic idea. | mean, people see superheroes all the time. However, 
nobody cares about them. Most are lonely and antisocial. SuperBook could change 
that. 


What do you think is different about Superbook? 


It is built from the ground up for people like us. | mean, there is no "Work and 
Education" nonsense when you want to use your secret identity. Though | don't have 
one, | can understand why one would. 


Could you tell us briefly some of the features you noticed? 


Sure, | think this is a pretty decent social network, where you can: 


* Sign up with any user name (no more, "enter your real name", silliness) 
。 Fans can follow people without having to add them as "friends" 

* Make posts, comment on them, and re-share them 

* Send a private post to another user 


Everything is easy. It doesn't take a superhuan effort to figure it out. Thanks for your 
time, Acorn. 


为 HTML 版 面 设计 
在 构建 Web 应 用 的 前 几 天 ， 像 Photoshop 和 Flash 这 样 的 工具 做 到 像素 级 别 的 模型 效果 使 用 是 
非常 广泛 的 。They are hardly recommended or used anymore. 


现在 对 智能 手机 、 平 板 、 笔 记 本 电脑 和 其 他 的 平台 保持 原生 和 体验 一 致 比 像素 层面 的 效果 更 
为 重要 了 。 实 际 上 ， 大 多 数 的 web 设 计 者 都 基于 HTML 构 建 布局 。 


Creating an HTML mockup is a lot faster and easier than before. If your web designer is 
unavailable, developers can use a CSS framework such as Bootstrap or ZURB Foundation 
framework to create pretty decent mockups. 


构建 一 个 HTML 版 本 相 比 以 前 快 了 很 多 。 如 果 你 暂时 还 没 找到 Web 设 计 ， 那 么 开发 者 可 以 利用 
Bootstrap 或 者 ZRUB 这 样 的 基本 的 CSS 框 架 来 构建 非常 漂亮 的 版 面 。 


The goal of creating a mockup is to create a realistic preview of the website. It should not 
erely focus on details and polish to look closer to the final product compared to a sketch, 

but add interactivity as well. Make your static HTML come to life with working links and some 
simple JavaScript-driven interactivity. 


构建 版 面 的 目的 就 是 为 了 创建 一 个 实际 上 可 用 网 站 的 预览 。 


Agood mockup can give 80 percent of customer experience with less than 20 percent of the 
overall development effort. 


一 个 好 的 版 面 可 以 达到 百 分 之 八 十 的 客户 体验 ， 以 及 少 于 百 分 之 二 十 的 总 的 开发 成 本 。 


设计 应 用 


"ou Ho m p e an 时 ， 你 可 以 开始 思考 如 何 使 用 Django 来 实现 
。 再 者 ， 这 可 以 诱导 人 开始 编程 。 然 而 ， 当 你 花 了 几 分 钟 时 间 来 思考 设计 时 ， 你 可 以 发 现 
Ht 党 多 的 不 同方 法 来 解决 一 个 设计 问题 。 


一 如 测试 驱动 的 开发 方法 论 中 提倡 的 那样 ， 你 也 可 以 首先 从 测试 开始 。 我 们 会 在 测试 章节 见 
到 更 多 的 TDD 方 法 。 我 们 会 在 测试 那 章 见 到 更 多 的 TDD 方 法 。 


Whichever approach you take, it is best to stop and think 一 "Which are the different ways in 
which I can ipleent this? What are the tradeoffs? Which factors are ore iportant in 
our context? Finally, which approach is the best? 


不 乱 你 选择 的 方式 是 哪 一 种 ， 最 好 是 停 下 来 想 一 想 一 一 ” 


Experienced Django developers look at the overall project in different ways. ticking to the 
DRY principle or soeties because they get lay, they think Have | seen this 

functionality before? For instance, can this social login feature be implemented using a third- 
party package such as django-all-auth? If they have to write the app themselves, they start 
thinking of various design patterns in the hope of an elegant design. However, they first need 
to break down a project at the top level into apps ° 


将 一 个 项 目 分 离 为 多 个 应 用 


Django 的 应 用 称 做 project。 一 个 项 目 由 多 个 应 用 或 者 apps 组 成 。 应 用 是 一 组 拥有 特定 功能 的 
Python é 


理论 上 说 ， 每 个 app 都 必须 是 可 以 重复 使 用 的 。 你 可 以 按照 自己 的 需要 创建 尽 可 能 多 的 app。 
绝对 不 要 害怕 添加 跟 多 的 app， 或 者 重 构 一 个 已 经 存在 的 应 用 到 多 个 app。 一 个 典型 的 Djanog 
项 目 包含 15 到 20 个 app。 


到 了 这 一 步 ， 一 个 重要 的 决定 就 是 是 否 使 用 Django 的 第 三 方 应 用 ， 还 是 从 零 编写 一 
方 应 用 是 无 需 你 自己 开发 ， 便 可 以 开 箱 即 用 的 。 大 多 数 的 包 都 可 以 很 快 “pa * JL 
分 钟 之 后 就 能 够 使 用 它们 。 


换 句 话 来 说 ， 编 写 自己 的 应 用 意味 着 要 常常 自己 设计 并 实现 模型 ， 视 图 ， 测 试 。Django 和 其 
他 类 型 的 应 用 并 没有 区 别 


用 自己 写 的 ， 还 是 使 用 别人 的 


One of Django's biggest strengths is the huge ecosystem of third-party apps. At the time of 
writing, djangopackages.com lists ore than , packages. You ight find that your 

copany or personal library has even ore. nce your project is broken into apps and you 
know which kind of apps you need, you will need to take a call for each app 一 whether to 
write or reuse an existing one. 


It might sound easier to install and use a readily available app. However, it not as simple as 
it sounds. Let's take a look at some third-party authentication apps for our project, and list 
the reasons why we didn't use them for SuperBook at the time of writing: 


Over-engineered for our needs: We felt that python-social-auth with support for any soc 
Too specific: Using django-facebook would mean tying our authentication to that provide 
Python dependencies: One of the requirements of django-allauth is python-openid, which 

Non-Python dependencies: Some packages might have non-Python dependencies, such as Redi 
Not reusable: Many of our own apps were not used because they were not very easy to reu 
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None of these packages are bad. They just don't meet our needs for now. They might be 
useful for a different project. In our case, the built-in Django auth app was good enough. On 
the other hand, you might prefer to use a third-party app for some of the following reasons: 


Too hard to get right Do your odel's instances need to for a tree? Use django-mptt for 
Best or recommended app for the job: This changes over time but packages such as django 
Missing batteries: Many feel that packages such as django-model-utils and django-extens 
Minimal dependencies: This is always good in my book 
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So, should you reuse apps and save tie or write a new custo app? | would recommend 
that you try a third-party app in a sandbox. If you are an intermediate Django developer, then 
the next section will tell you how to try packages in a sandbox. 


我 的 app 沙 条 


From time to time, you will come across several blog posts listing the "must-have Django 
packages". However, the best way to decide whether a package is appropriate for your 
project is Prototyping. 


Even if you have created a Python virtual environment for development, trying all these 
packages and later discarding them can litter your environment. So, | usually end up 
creating a separate virtual environment named "sandbox" purely for trying such apps. Then, 
| build a small project to understand how easy it is to use. 


Later, if | am happy with my test drive of the app, | create a branch in my project using a 
version control tool such as Git to integrate the app. Then, | continue with coding and 
running tests in the branch until the necessary features are added. Finally, this branch will be 
reviewed and merged back to the mainline (sometimes called master) branch. 


它 是 由 哪个 包 组 成 的 ? 
为 了 阅 明 过 程 ， 我 们 的 SuperBook 项 目 可 以 粗略 地 分 解 为 下 列 app (没有 全 部 列 出 ) 
Authentication ( ^i € django. auth): 这 个 app 处 理 用 户 注册 ， 登 录 ， 和 登 出 。 
Accounts (定制 ) : 这 个 app 提 偶 那个 额外 的 用 户 账 户 信 息 。 Posts (定制 ) : 这 个 app 提 
供 发 表 和 回复 功能 Pows (定制 ) : 这 个 app 跟 中 有 多 少 " 碰 ”( 支持 或 者 喜欢 ) Boostrap 
forms (crispy-forms) : 这 个 app 处 理 表 单 布 局 和 风格 


这 里 ， 一 个 app 已 经 被 标记 为 从 零 (标记 为 “定制 ") 构建 ， 或 者 我 们 要 使 用 的 第 三 方 Django 应 
用 。 随 着 ， 项 目的 发 展 ， 这 些 选项 或 许 改变 。 不 过 ， 这 对 一 个 新 手足 够 了 。 


在 开始 项 目 之 前 
While preparing a development environment, make sure that you have the following in place: 


* A fresh Python virtual environment: Python 3 includes the venv module or you can instal 
e Version control: Always use a version control tool such as Git or Mercurial. They are 1 
* Choose a project template: Django's default project template is not the only option. Ba 
* Deployment pipeline: I usually worry about this a bit later, but having an easy deploym 
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SuperBook- 少 年 来 吧 ， 接 受 你 的 任务 


This book believes in a practical and pragmatic approach of demonstrating Django design 
patterns and the best practices through examples. For consistency, all our examples will be 
about building a social network project called SuperBook. 


SuperBook focusses exclusively on the niche and often neglected market segment of people 
with exceptional super powers. You are one of the developers in atea comprised of other 
developers, web designers, a marketing manager, and a project manager. 


The project will be built in the latest version of Python (Version 3.4) and Django (Version 1.7) 
at the time of writing. Since the choice of Python 3 can be a contentious topic, it deserves a 
fuller explanation. 


为 什么 选 Python 3? 


While the development of Python started in , its first release, Python ., was 

released on December 3, 2008. The main reasons for a backward incompatible version were 
一 Switching to Unicode for all strings, increased use of iterators, cleanup of deprecated 
features such as old-style classes, and some new syntactic additions such as the nonlocal 
statement. 


The reaction to Python 3 in the Django community was rather mixed. Even though the 
language changes between Version 2 and 3 were small (and over time, reduced), porting the 
entire Django codebase was a significant igration effort. 


n February , Django . becae the first version to support Python . Developers 
have clarified that, in future, Django will be written for Python with an ai to be backward 
compatible to Python 2. 


For this book, Python 3 was ideal for the following reasons: 
就 本 书 来 说 ，Python 3 由 于 以 下 几 个 原因 看 来 它 是 最 理想 的 : 


e Better syntax This fixes a lot of ugly syntaxes, such as izip, xrange, and unicode, with 
the cleaner and more straightforward zip, range, and _ str 


e Sufficient third-party support: Of the top 200 third-party libraries, more than 80 percent 
have Python 3 support. 


* No legacy code: We are creating a new project, rather than dealing with legacy code that 
needs to support an older version. 


不 存在 遗留 的 代码 : 我 们 创建 一 个 新 的 项 目 ， 而 不 是 来 处 理 需要 支持 旧版 本 代码 。 


* Default in modern platforms: This is already the default Python interpreter in Arch Linux. 
Ubuntu and Fedora plan to complete the switch in a future release. 


* It is easy: From a Django development point of view, there are very few changes, and they 
can all be learnt in a few minutes. 


使 用 方便 : 站 在 Django 开 发 的 观点 来 看 ， 其 改变 非常 微小 ， 所 有 变更 的 地 方 学 起 来 也 很 快 。 


The last point is important. Even if you are using Python 2, this book will serve you fine. 
Read appendix to understand the changes. You will need to make only minimal 
adjustments to backport the example code. 


最 后 一 点 很 重要 。 即 使 你 现在 使 用 的 是 Python 2， 本 书 中 的 例子 也 能 够 很 好 的 运行 。 


开始 项 目 


本 节 是 SuperBook 项 目的 安装 说 明 ， 它 包含 在 本 书 中 使 用 的 所 有 代码 实例 。 要 为 最 新 的 安装 
注释 检查 项 目的 README 文 件 。 推 荐 你 创建 一 个 新 的 目录 ，suUperbook， 首 先 包含 虚拟 环 
境 ， 项 目 源码 。 


Ideally, every Django project should be in its own separate virtual environment. This makes it 
easy to install, update, and delete packages without affecting other applications. In Python 
3.4, using the built-in venv module is recommended since it also installs pip by default: 


理论 上 ， 每 一 个 Django 项 目 都 应 该 有 自己 的 虚拟 环境 。 使 用 虚拟 环境 可 以 让 Django 的 安装 ， 
升级 显得 很 轻松 ， 而 且 删 除 包 也 不 会 影响 到 其 他 的 应 用 。 在 Python 3.4 中 ， 建 议 使 用 内 建 的 
Venv 模 块 ， 因 为 它 默 认 也 安装 了 pip: 


$ python3 -m venv sbenv 
$ source sbenv/bin/activate 
$ export PATH=" pwd /sbenv/local/bin:$PATH" 


These commands should work in most Unix-based operating systems. For installation 
instructions on other operating systems or detailed steps please refer to the README file at 
the ithub repository https://github.com/DjangoPatternsBook/ superbook. In the first line, 
we are invoking the Python . executable as python3; do confir if this is correct for your 
operating syste and distribution. 


这 些 命令 可 以 运行 在 大 多 数 的 基于 Unix 的 操作 系统 。 例 如 


The last export command might not be required in some cases. If running pip freeze lists 
your system packages rather than being empty, then you will need to enter this line. 


ipae export ^p fe Fin 情况 下 不 是 必须 的 。 如 果 运 行 pip freeze 列 出 的 系统 包 
是 空 的 ， 那 么 你 需要 输入 这 一 行 


开始 Django 项 目 之 前 ， 创 建 一 个 新 的 虚拟 环境 


$ git clone https://github.com/DjangoPatternsBook/superbook.git 
$ cd superbook 
$ pip install -r requirements.txt 


如 果 你 想 看 一 看 已 完成 的 SuperBook 网 站 ， 只 要 运行 migrate 并 启动 测试 服务 器 就 行 了 : 


$ cd final 

$ python manage.py migrate 

$ python manage.py createsuperuser 
$ python manage.py runserver 


In Django 1.7, the migrate command has superseded the syncdb command. We also need 
to explicitly invoke the createsuperuser command to create a super user so that we can 
access the admin. 

在 Django1.7 中 ，migrate 命 令 已 经 取代 了 syncdb 命 令 。 我 们 也 需要 明确 地 调用 
creteasuperuser 命 令 来 创建 一 个 超级 用 户 ， 这 样 我 们 就 可 以 访问 admin 了 。 

You can navigate to http://127.0.0.1:8000 or the URL indicated in your terminal and feel free 
to play around with the site. 


你 可 以 浏览 hnttp://127.0.0.1:8000 或 者 在 终端 指明 URL， 随 便 玩 玩 这 个 网 站 。 
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Beginners often underestimate the importance of a good requirements-gathering process. At 
the same time, it is important not to get bogged down with the details, because programming 
is inherently an exploratory process. The most successful projects spend the right amount of 
time preparing and planning before development so that it yields the maximum benefits. 


新 手 总 是 低估 了 一 个 优质 的 请 求 一 获取 流程 的 重要 性 。 于 此 同时 ， 重 要 的 是 不 要 被 细节 所 束 
缚 ， 因 为 从 本 质 来 说 ， 编 程 就 是 一 个 探索 的 过 程 。 很 多 成 功 的 项 目 在 开发 之 前 都 花 掉 了 大 量 
的 时 间 来 准备 和 计划 ， 这 样 才能 获得 最 佳 效 果 。 

We discussed many aspects of designing an application, such as creating interactive 


mockups or dividing it into reusable components called apps. We also discussed the steps 
to set up SuperBook, our example project. 


我 谈论 了 设计 应 用 的 很 多 方面 ， 比 如 创建 交互 模型 ， 或 者 是 将 它 分 割 到 多 个 称 为 app 的 可 重复 
使 用 组 件 。 同 时 我 们 也 讨论 了 配置 项 目 SuperBook 的 步骤 。 


In the next chapter, we will take a look at each component of Django in detail and learn the 
design patterns and best practices around them. 


在 下 一 章 ， 我 们 会 详细 地 浏览 Django 的 每 个 组 件 ， 并 学 习 与 这 些 组 件 相关 的 最 佳 实践 。 
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第 三 草 模型 
本 章 ， 我 们 将 讨论 以 下 话题 : 


模型 的 重要 性 
类 图 表 

模型 结构 模式 
QE 
迁移 


Mit VEC ÆA 


在 Diango 中 ， 模 型 是 具有 处 理 数 据 库 的 一 种 面向 对 象 的 方法 的 类 。 通 常 ， 每 个 类 都 引用 一 个 
数据 库 表 ，， 每 个 属性 都 引用 一 个 数据 库 列 。 你 可 以 使 用 自动 生成 的 API 查 询 这 些 表 。 


模型 是 很 多 其 他 组 件 的 基础 。 只 要 你 有 一 个 模型 ， 你 可 以 快速 地 推导 模型 admin， 模 型 表单 ， 
以 及 所 有 类 型 的 通用 视图 。 在 每 个 例子 中 ， 你 都 需要 下 一 个 行 或 是 两 行 代码 ， 这 样 可 以 让 它 
看 上 去 没有 太 多 魔法 。 


模型 也 被 用 在 更 多 超出 你 期 望 的 地 方 。 这 书 因为 Django 可 以 以 多 种 方法 运行 。Django 的 一 些 
切入 点 如 下 : 


熟悉 web 请 求 -响应 流程 
Django 的 交互 式 shell 
管理 命令 

测试 脚本 

异步 任务 队列 比如 Celery 


在 多 数 的 这 些 例子 中 ， 模 型 模块 要 导入 (作为 django.setup() 的 一 部 分 ) 。 因 此 ， 最 好 保证 模 
型 远离 任何 不 必要 的 依赖 ， 或 者 导入 任何 的 其 他 Django 组 件 ， 比 如 视图 。 


简 而 言 之 ， 恰 当地 设计 模型 是 很 重要 的 事情 。 现 在 ， 让 我 们 从 SuperBook 模 型 设计 开始 。 
注释 


自 带 午餐 便当 
* 作 者 注释 : SuperBook 项 目的 进度 会 以 这 样 的 一 个 盒子 出 现 。 你 可 以 跳 过 这 个 盒子 ， 但 是 在 
Web 应 用 项 目 中 的 情况 下 ， 你 缺少 的 是 领悟 ， 经 验 。 
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监控 (简称 为 S.H.I.M) 。 简 单 来 说 ， 这 是 一 个 大 杂 
公 室 是 非常 rie Fo uide, 事情 都 需要 上 百 个 审核 和 签字 。 








作为 Django 开 发 者 的 领队 ， 史 蒂 夫 已 经 配置 好 了 中 型 的 运行 超过 两 天 的 4 台 虚 拟 机 。 第 二 天 的 
一 个 早晨 ， 机 器 自己 不 要 而 飞 了 。 一 个 附近 的 清洁 机 器 人 说 ， 机 器 被 法 务 部 们 给 带 走 了 ， 他 
们 要 对 未 经 审核 的 软件 安装 做 出 处 理 。 


然而 ，CTO 哈 特 给 予 史 莆 夫 了 极 大 的 帮助 。 他 要 求 机 器 在 一 个 小 时 之 内 完好 无 损 地 给 还 回 
去 。 他 还 对 SuperBook 项 目 做 出 了 提前 审核 以 避免 将 来 可 能 出 现 的 任何 阻碍 。 

那个 下 午 的 稍 晚 些 时 候 ， 史 带 夫 给 他 带 了 一 个 午餐 便当 。 身 着 一 件 米色 外 套 和 浅 蓝 色 牛 仔裤 
的 哈 特 如 约 而 至 。 尽 管 高 出 周围 人 许多 ， 有 着 清 严 面庞 的 他 依旧 那么 帅气 ， 那 么 平易 近 人 。 
他 问 史 蒂 夫 如 果 他 之 前 是 否 尝试 过 构建 一 个 60 年 代 的 超级 英雄 数据 库 。 

" 咽 ， 对 的 ， 是 哨兵 项 目 么 ?2"， 史 和 荫 夫 说 道 。" 是 我 设计 的 。 数 据 库 看 上 去 被 设计 成 了 一 个 条 
目 - 属 性 - 值 形式 的 模式 ， 有 些 地 方 我 考虑 用 反 模 式 。 可 能 ， 这 些 天 他 们 有 一 些 超 级 英雄 属性 的 
小 想法 。 哈 特 几 乎 等 不 到 听 完 最 后 一 句 ， 他 压低 嗓门 道 : “ 没 错 。 是 我 的 错 。 另 外 ， 他 们 只 给 
了 我 两 天 来 设计 整个 架构 。 他 们 这 是 在 要 我 老 命 啊 1” 

听 了 这 些 ， 史 荫 夫 的 嘴巴 张 的 大 大 的 ， 三 明治 也 卡 在 口中 。 哈 特 微笑 着 道 : “当然 了 ， 我 还 没 
有 尽 全 力 来 做 这 件 事 。 只 要 它 成 长 为 100 万 美元 的 单子 ， 我 们 就 可 以 多 花 点 时 间 在 这 该 死 的 数 
据 库 上 了 。SuperBook 用 它 就 能 分 分 钟 完事 的 ， 小 史 你 说 呢 ?” 


史 幕 夫 微 微 点 头 称 是 。 他 从 来 没有 想 过 在 这 么 样 的 地 方 将 会 有 上 百 万 的 超级 英雄 出 现 。 


AL = 

模型 搜寻 

这 是 在 SuperBook 中 确定 模型 的 第 一 部 分 。 通 常 对 于 一 个 早期 试验 ， 我 们 只 表示 了 基本 模 

型 ， 以 及 在 一 个 类 表 中 的 表单 的 基本 关系 : 

图 : 略 

让 我 们 忘掉 模型 一 会 儿 ， 来 谈 谈 我 们 正在 构建 的 对 象 的 术语 。 每 个 用 户 都 有 一 个 账户 。 用 户 
可 以 写 多 个 回复 或 者 多 篇 文章 。Like 可 以 同时 关联 到 一 个 单独 的 用 户 或 者 文章 。 

推荐 你 像 这 样 画 一 个 模型 的 类 表 。 这 个 步骤 的 菜 些 属性 或 许 缺 失 了 ， 不 过 你 可 以 在 之 后 补充 
细节 。 只 要 整个 项 目 用 图 表 表 示 出 来 ， 便 可 以 轻松 地 分 离 app。 


这 是 创建 此 表示 的 一 些 提 示 : 


金子 表 示 条 目 ， 它 将 成 为 模型 。 
名 词 通常 作为 条 目的 终止 。 

箭头 是 双向 的 ， 表 示 Django 中 三 种 关系 类 型 其 中 的 一 种 : 一 对 一 ， 一 对 多 (通过 外 键 实现 ) ， 和 多 对 多 。 
字段 表明 在 基于 条 目 -关系 模型 (ER-modle) 的 模型 中 定义 了 一 对 多 关系 。 换 句 来 说 ， 星 号 是 声明 外 键 的 地 方 。 


类 图 表 可 以 映射 到 下 面 的 Django 代 码 中 ( 它 将 遍及 多 个 app ) 


class Profile(models.Model): 
user = models.OnToOneField(User ) 


class Post(models.Model): 
posted by = models.ForeignKkey (User ) 


class Comment(models.Model): 
commented by = models.ForeignKey(User) 
for post - models.ForeignKey(Post) 
class Like(models.Model): 


liked by - models.ForeignKey(User) 
post - models.ForeignKey(Post) 


这 之 后 ， 我 们 不 会 直接 地 引用 User， 而 是 使 用 更 加 普通 的 settings.AUTH_USER_MODEL 来 
替代 。 


分 割 model.py 到 多 个 文件 


就 像 多 数 的 Django 组 件 那样 ， 一 个 大 的 model.py 文 件 可 以 在 一 个 包 内 分 割 为 多 个 文 
件 。package 通 过 一 个 目录 来 实现 ， 它 包含 多 个 文件 ， 目 录 中 的 一 个 文件 必须 是 一 个 称 
为 _init .py 特殊 文件 。 


所 有 可 以 在 包 级 别 中 暴露 的 定义 都 必须 在 _ init .py 里 使 用 全 局 变量 域 定义 。 例 如 ， 如 果 我 
们 分 割 model.py 到 独立 的 类 ，models 子 文件 夹 中 的 对 应 文件 ， 比 如 ，postable.py，post.py 和 
comment.py, 之 后 init .py 包 会 像 这 样 : 


from postable import Postable 
from post import Post 
from commnet import Comment 


现在 你 可 以 像 之 前 那样 导入 models.Post 了 。 


在 _ init. .py 包 中 的 任何 其 他 代码 都 会 在 包 运 行 时 被 导入 。 因 此 ， 它 是 一 个 任意 级 别 包 初 始 
化 代码 的 理想 之 地 。 


本 节 和 包含 多 个 帮助 你 设计 和 构建 模型 的 设计 模式 。 


模 忒 -规范 化 模型 
问题 : 通过 设计 ， 模 型 实例 的 重复 数据 引起 数据 不 一 致 。 


解决 方法 : 通过 规范 化 ， 分 解 模 型 到 更 小 的 模型 。 使 用 这 些 模 型 之 间 的 逻辑 关系 来 连接 他 
们 。 


问题 细节 


想象 一 下 ， 如 果 某 人 用 下 面 的 方法 设计 Post 表 (省 略 部 分 列 ) 


超级 英雄 的 名 字 消息 发 布 时 间 
Captain Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:15 
Professor English 应 该 用 “|ls” 而 不 是 “Has" 2012/07/07/07:17 
Captain Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:18 
Capt. Temper 消息 已 经 发 布 过 了 ? 2012/07/07/07:19 


我 希望 你 注意 到 了 在 最 后 一 行 的 超级 英雄 名 字 和 之 前 不 一 致 (船长 一 如 既往 的 缺乏 耐心 ) o 


如 果 我 们 看 看 第 一 列 ， 我 们 也 不 确定 哪 一 个 拼写 是 正确 的 
Captain Temper 或 者 Capt.Temper 。 这 就 是 我 们 要 通过 规范 化 消除 的 一 种 数据 宛 余 。 





详解 

在 我 们 看 下 完整 的 规范 方案 ， 让 我 们 用 Django 模 型 的 上 下 文 来 个 关于 数据 库 规 范 化 的 简要 说 
AR] e 

规范 化 的 三 个 步骤 

规范 化 有 助 于 你 更 有 效 地 的 存储 数据 库 。 只 要 模型 完全 地 的 规范 化 处 理 ， 他 们 就 不 会 有 宛 余 
的 数据 ， 每 个 模型 应 该 只 包含 逻辑 上 关联 到 自身 的 数据 。 


这 里 给 出 一 个 简单 的 例子 ， 如 果 我 们 规范 化 了 Post 表 ， 我 们 就 可 以 不 模棱两可 地 引用 发 布 消 
息 的 超级 英雄 ， 然 后 我 们 需要 用 一 个 独立 的 表 来 隔离 用 户 细节 。 上 默认 ，Django 已 经 创建 了 用 
户 表 。 因 此 ， 你 只 需要 在 第 一 列 中 引用 发 布 消息 的 用 户 的 ID， 一 如 下 表 所 示 : 


用 户 1D 消息 发 布 时 间 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:15 
8 应 该 用 “le” 而 不 是 “Has" 2012/07/07/07:17 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:18 
12 消息 已 经 发 布 过 了 ? 2012/07/07/07:19 


现在 ， 不 仅仅 相同 用 户 发 布 三 条 消息 的 清楚 在 列 ， 而 且 我 们 可 以 通过 查询 用 户 表 找到 用 户 的 
正确 的 名 字 。 


通常 来 说 ， 你 会 按照 模型 的 完全 规 规范 化 表 来 设计 模型 ， 也 会 因为 性 能 原因 而 有 选择 性 地 非 
规范 化 设计 。 在 数据 库 中 ，Normal Forms 是 一 组 可 以 被 应 用 于 表 ， 确 保 表 被 规范 化 的 指南 。 
一 般 我 们 建立 第 一 ， 第 二 ， 第 三 规范 表 ， 尽 管 他 们 可 以 递增 至 第 五 规范 表 。 


这 接 下 来 的 例子 中 ， 我 们 规范 化 一 个 表 ， 创 建 对 应 的 Django 模 型 。 想 象 下 有 个 名 字 称 
做 “Sightings” 的 表格 ， 它 列 出 了 某 人 第 一 次 发 现 超级 英雄 使 用 能 力 或 者 特异 功能 。 每 个 条 目 都 
提 到 了 已 知 的 原始 身份 ， 超 能 力 ， 和 第 一 次 发 现 的 地 点 ， 包 括 维 度 和 经 度 。 


第 一 次 使 用 记录 (维度 ， 经 度 ， 国 家 ， 时 


Ea 么 信 自 25 
Au 原始 信息 能 力 间 ) 
Blitz Alien Freeze Flight +40.75, -73.99; USA; 2014/07/03 23:12 
Hexa Scientist hc 435.68, 4139.73; Japan; 2010/02/17 20:15 
Traveller Billonaire Time travel *43.62, +1.45, France; 2010/11/10 08:20 


Ed 55 3532 2: 3E 42 FX A http://www.golombek.com/locations.html. 


第 一 规范 表 (1NF) 
为 了 确认 第 一 个 规范 表格 ， 这 张 表 必须 含有 : 


多 个 没有 属性 (cell) 的 值 
一 个 主键 作为 单独 一 列 或 者 一 组 列 〈 合 成 键 ) 
让 我 们 试 着 把 表格 转换 为 一 个 数据 库 表 。 明 显 地 ， 我 们 的 Power 列 破 坏 了 第 一 个 规则 。 
更 新 过 的 表 满 足 第 一 规范 表 。 主 键 (用 一 个 * 标记 ) 是 Name 和 Power 的 合并 ， 对 于 每 一 排 


它 都 应 该 是 唯一 的 。 


Name* Origin Power* Latitude Longtitude Country Time 


Blitz |Alien |Freeze|*40.75170 |-73.99420|USA|2014/07/03 23:12| 
Blitz|Alien|Flight|+40.751 70|-73.99420|USA|2013/03/12 11:30] 

Hexa|Scientist| Telekinesis|+35.68330|+139.73330|Japan|2010/02/17 20:15| 
Hexa|Scientist|Filght|+35.68330|+139.73330|Japan|2010/02/19 20:30] 
Traveller|Billionaire|Time tavel|+43.61670|+1.45000|France|2010/11/10 08:20| 


第 二 规范 表 


第 二 规范 表 必 须 满足 所 有 第 一 规范 表 的 条 件 。 此 外 ， 它 必须 满足 所 有 非 主键 列 都 必须 依赖 于 
整个 主键 的 条 件 。 


在 之 前 的 表 ， 我 们 注意 到 origin RPM PARRA > BP > name 。 不 论 我 们 谈论 的 是 哪 一 
个 Power 。 因 此 ， Origin 不 是 完全 地 依赖 于 合成 组 件 - Name 和 Power ° 


这 里 ， 让 我 们 只 取出 原始 信息 到 一 个 独立 的 ， 称 做 origins 的 表 : 


Name* Origin 


Blitz|Alien| Hexa|Scientist| Traveller|Billionaire| 
现在 Sightings 表 更 新 为 兼容 第 二 规范 表 ， 它 大 概 是 这 个 样子 : 


Name* Power* Latitude Longtitude Country Time 


Blitz |Freeze|+40.75170 |-73.99420|USA|2014/07/03 23:12 
Blitz||Flight|+40.75170|-73.99420|USA|2013/03/12 11:30] 
Hexa|Telekinesis|*35.68330|*139.73330|Japan|2010/02/17 20:15] 
HexalFilght|+35.68330|+139.73330|Japan|2010/02/19 20:30] Traveller|Time 
tavel|+43.61670|+1.45000|France|2010/11/10 08:20 


第 三 规范 表 
在 第 三 规范 表 中 ， 比 表格 必须 满足 第 二 规范 表 ， 而 且 应 该 额外 满足 所 有 的 非 主键 列 都 直接 依 


赖 整个 主键 ， 而 且 这 些 非 主 键 列 都 是 互相 独立 的 这 个 条 件 。 


考虑 下 country 类 。 给 出 维度 和 经 度 ， 你 可 以 轻松 地 得 出 country 列 。 即 使 观测 到 超级 英雄 
的 地 方 依赖 于 Name-Power 合成 键 ， 但 是 它 只 是 间接 地 依赖 他 们 。 


因此 ， 我 们 把 详细 地 址 分 离 到 一 个 独立 的 国家 表格 中 : 
Location ID Latitude* Longtitude* Country 


1|+40.75170|-73.99420|USA| 2|+35.68330|+139.73330|Japan| 
3|+43.61670|+1.45000|France| 


现在 sightings 表格 的 第 三 规范 表 大 抵 如 此 : 


User 1D* Power* Location ID Time 
2 Freeze 1 2014/0703 23:12 
2 Flight 1 2013/03/12 11:30 
4 Telekinesis 2 2010/02/17 20:15 
4 Flight 2 2010/02/19 20:30 
7 Time tavel 3 2010/11/10 08:20 


如 之 前 所 做 的 那样 ， 我 们 用 对 应 的 user ID 替换 了 超级 英雄 的 名 字 ， 这 个 用 户 ID 用 来 引用 用 
PORA 


Django 模 型 


现在 我 们 可 以 看 看 这 些 规范 化 的 表格 可 以 用 来 表现 Django 模 型 。Django 中 并 不 直接 支持 合成 
键 。 这 里 用 到 的 解决 方案 是 应 用 代理 键 ， 以 及 在 Meta 类 中 指定 unique together 属性 : 


class Origin(models.Model): 
superhero = models.ForeignKey(settings.AUTH USER MODEL) 
origin = models.CharField(max length-100) 


class Location(models.Model): 
latitude - models.FloatField() 


longtitude - models.FloatField() 
country = models.CharField(max_length=100) 


class Meta: 
unique together - ("latitude", "longtitude") 


class Sighting(models.Model): 
superhero - models.ForeignKey(settings.AUTH USER MODEL) 
power = models.CharField(max_length=100) 


location - models.ForeignKey(Location) 
sighted on = models.DateTimeField() 


class Meta: 
unique together - ("superhero", "power") 


ME fie de FEAL wT 


规范 化 可 能 对 性 外 aa 需要 应 答 查 询 的 连接 数 也 随 之 增加 。 例 
如 ， ae a 人 S 冻 能 力 的 超级 英雄 的 数量 ， 你 需要 连接 四 个 表格 。 先 前 的 内 容 规范 
， 任何 信息 都 可 以 通 Re 


应 udo 保持 数据 规 。 这 可 以 维持 数据 的 完整 性 。 然 而 ， 如 果 你 面临 扩展 性 问 
， 你 可 以 有 选择 性 地 从 这 av 型 取得 数据 以 生成 非 规范 化 的 数据 。 


提示 


最 佳 实践 因 设计 而 规范 ， 又 因 优 化 而 非 规 范 例如， 在 一 个 确定 的 国家 中 计算 观测 次 数 是 非常 
普通 的 ， 然 后 将 观测 次 数 作为 一 个 附加 的 字段 到 Location 模型 。 现 在 ， 你 可 以 使 用 Django 
ORM 继承 其 他 的 查询 ， 而 不 是 一 个 缓存 的 值 。 

然而 ， 你 需要 在 每 次 添加 或 者 移 除 观测 时 更 新 这 个 计数 。 你 需要 添加 本 次 计算 到 Singhting 
的 save 方法 ， 添 加 一 个 信号 处 理 器 ， 甚 至 使 用 一 个 异步 任务 去 计算 。 


如 果 你 有 一 个 跨越 多 个 表 的 负责 查询 ， 比 如 国家 的 超 能 力 计算 ， 你 需要 创建 一 个 独立 的 非 规 
范 表格 。 就 像 前 面 那 样 ， 我 们 需要 在 每 一 次 规范 化 模型 中 的 数据 改变 时 更 新 这 个 非 规 范 的 表 
" o 


令 人 惊讶 的 是 非 规 范 化 在 大 型 的 网 站 中 是 非常 普遍 的 ， 因 为 它 是 数 度 和 存储 空间 两 者 之 问 的 
折衷 。 今 天 的 存储 空间 已 经 比较 便宜 了 ， Raid LHR MP EXNTIXÉRH—RE. 因此 ， 
如 果 你 的 查询 耗 时 过 于 久 的 话 ， 那 么 就 需要 考虑 非 规范 化 了 。 


我 们 应 该 一 直 使 用 规范 化 吗 ? 
过 多 的 规范 化 是 是 件 不 必要 的 事 。 有 时 候 ， 它 可 以 引入 一 个 非 必需 的 能 够 重复 更 新 和 查询 的 
表格 。 


例如 ， 你 的 User 模型 或 许 有 好 多 个 家 庭 地 址 的 字段 ， 你 可 以 规范 这 些 字 段 到 一 个 Address JE 
型 中 。 可 是 ， 多 数 情 况 下 ， 把 一 个 额外 的 表 引 进 数 据 库 是 没有 必要 的 。 


ee ra ae 个 非 规范 化 的 机 会 ， 对 
能 和 速度 上 做 出 一 个 折衷 的 选择 。 


模式 -模型 mixins 
问题 : 明显 地 模型 含有 重复 的 相同 字段 /或 者 方法 ， 违 反 了 DRY 原 则 。 


方案 : 提取 公共 字段 和 方法 到 各 种 不 同 的 可 复 用 的 模型 mixins 中 。 


问题 细节 


设计 模型 时 ， 你 或 许 某 些 公共 属性 或 者 行为 跨 模 型 类 共享 。 例 如 ， post 和 comment 模型 需要 
一 直 跟 踪 自己 的 created 日 期 和 modified 日 期 。 手 动 地 复制 -粘贴 字段 和 它们 所 关联 的 方法 十 
分 不 符合 DRY 原 则 。 


由 于 Django 的 模型 是 类 ， 像 合成 以 及 继承 这 样 的 面向 对 象 方法 都 是 可 以 选择 的 解决 方案 。 然 
而 ， 合 成 (具有 包含 一 个 共享 类 实例 的 属性 ) 需要 一 个 额外 的 间接 层 访 问 字 段 。 


继承 是 有 技巧 的 。 我 们 可 以 对 Post 和 comment 使 用 一 个 公共 基 类 。 然 而 ， 在 Django 中 有 三 种 
类 型 的 继承 : concrete (具体 ) , abstract (抽象 ) , feproxy (代理 ) 。 


而 具体 继承 的 运行 视 派 生 基 类 而 定 ， 就 像 你 在 Python 类 中 通常 用 到 的 那样 。 不 过 ， 在 Django 
中 ， 这 个 基 类 将 被 映射 到 一 个 独立 的 表 中 。 每 次 你 访问 基本 字段 时 ， 都 需要 一 个 明确 的 连 
do EAE RLS it RK SIE H 7B 7K 19 TE AG] Do 

代理 继承 只 能 添加 新 的 行为 到 父 类 。 你 不 能 够 添加 新 字段 。 因 此 ， 这 种 情况 下 它 的 用 处 也 不 
ds 


最 后 ， 我 们 只 有 寄 希 望 于 抽象 继承 了 。 


抽象 基 类 是 用 于 模型 之 间 共 享 数据 和 行为 的 简洁 方案 。 当 你 定义 一 个 抽象 类 时 ， 它 在 数据 库 
中 并 没有 创建 任何 与 之 对 象 的 表 。 相 反 ， 这 些 字段 是 在 派生 出 来 的 非 抽 象 类 中 创建 的 。 


访问 抽象 基 类 字段 不 需要 JOIN 语句 。 带 有 可 管理 字段 的 结果 表格 也 是 不 解 自 明 的 。 为 了 利用 
这 些 优点 ， 大 多 数 的 Django 项 目 都 使 用 抽象 基 类 实现 公共 字段 或 者 方法 。 


抽象 模型 的 局 限 在 于 


© 它们 不 能 够 拥有 外 键 或 者 其 他 模型 的 多 对 多 字段 。 
© 它们 不 能 够 被 实例 化 或 者 保存 起 来 。 
e 它们 查询 中 不 能 够 直接 地 使 用 ， 因 为 它 没有 管理 器 。 
下 面 展 示 了 post 和 comment 类 如 何 使 用 一 个 抽象 基 类 进行 初始 设计 : 


class Postable(models.Model): 
created = models.DateTimeField(auto now add-True) 
modified = modified.DateTimeField(auto  now-True) 
message = models.TextField(max length-5060) 
class Meta: 
abstract - True 


class Post(Postable): 


class Comment(Postable): 


要 将 一 个 模型 转换 到 抽象 基 类 ， 你 需要 在 它 的 内 部 meta 类 中 写 上 abstract = True 。 这 里 
的 Postable 是 一 个 抽象 基 类 。 E ， 它 不 是 那么 的 可 复 用 。 


实际 上 ， 如 果 有 一 个 类 含有 created 和 modified 字段 ， 我 们 在 后 面 就 可 以 在 几乎 任何 需要 时 
间 改 的 模型 中 重复 使 用 这 个 时 间 改 功能 。 


模型 mixins 
模型 mixins 是 一 个 可 以 把 抽象 类 当 作 父 类 来 添加 的 模型 。 不 像 其 他 的 语法 ， 比 如 Java 那 样 ， 
Python 支持 多 种 继承 。 因 此 ， 你 可 以 列 出 一 个 模型 的 任意 数量 的 父 类 。 


Mixins 应 该 是 互相 垂直 的 而 且 易 于 组 合 的 。 把 一 个 mixin 放 进 基 类 的 列表 ， 这 些 mixin 应 该 可 以 
正常 运行 。 这 样 看 来 ， 它 们 在 行为 上 更 类 似 于 合成 而 非 继承 。 


小 一 些 mixin 的 会 好 很 多 。 不 论 何 时 当 一 个 mixin 变 得 很 大 ， 而 且 又 违反 了 独立 响应 原则 ， 就 要 
考虑 把 它 重 构 到 一 个 小 一 些 的 类 中 去 。 就 让 mixin 一 次 做 好 一 件 事 吧 。 


在 前 面 的 例子 中 ， 用 于 更 新 created 和 modified 的 时 间 的 模型 mixin 可 以 轻松 地 分 解 出 来 ， 一 
如 下 面 代 码 所 示 : 


class TimeStampedModel(models.Model): 
created = modified. TimeStampModel(auto_now_add=True) 
modified = modified.DateTimeField(auto_now=True) 


class Meta: 
abstract = True 


class Postable(TimeStampedModel): 
message = models.TextField(max length-500) 


class Meta: 
abstract - True 


class Post(Postable): 


class Comment(Postable): 


我 们 现在 有 两 个 超 类 了 。 不 过 ， 功 能 之 间 显 然 都 是 独立 的 。mixin 可 以 分 离 到 自己 的 模块 之 
内 ， 或 者 在 其 他 的 上 下 文中 被 重复 利用 。 


ak ` > > 

模式 -用 户 账户 

问题 : 每 一 个 网 站 都 存储 一 组 不 同 的 用 户 账户 细节 。 然 而 ，Django 的 内 建 user 模型 由 在 针对 
认证 细节 。 


方案 : 用 一 对 一 关系 的 用 户 模 型 ， 创 建 一 个 用 户 账户 类 。 


问题 细节 


Django 提 供 一 个 开 箱 即 用 的 相当 不 错 的 User 模 型 。 你 可 以 在 创建 超级 用 户 或 者 登录 amdin 接 
口 的 时 候 用 到 它 。 它 含有 少量 的 基本 字段 ， 比 如 全 名 ， 用 户 名 ， 和 电子 邮件 。 


然而 ， 大 多 数 的 现实 世界 项 目 都 保留 了 很 多 关于 用 户 的 信息 ， 比 如 他 们 的 地 址 ， 喜 欢 的 电 
影 ， 或 者 它们 的 超 能 力 。 打 Dijango1.5 开 始 ， 默 认 的 User 模 型 就 可 以 被 扩展 或 者 替换 掉 。 不 
过 ， 官 方 文档 极力 推荐 只 存储 认证 数据 ， 即 便 是 在 定制 的 用 户 模型 中 也 是 如 此 (毕竟 ， 用 户 
模型 也 是 所 属于 auth 这 个 app 的 ) 。 


某 些 项 目 是 需要 多 种 类 型 的 用 户 的 。 例 如 ，SuperBook 可 以 被 超级 英雄 和 非 超级 英雄 所 使 
用 。 这 里 或 许 会 有 一 些 公共 字段 ， 以 及 基于 用 户 类 型 的 不 同 字段 。 


详解 
官方 推荐 解决 方案 是 创建 一 个 用 户 账户 模型 。 它 应 该 和 用 户 模 型 有 一 个 一 对 一 的 关系 。 
的 全 部 用 户 信息 都 存储 于 该 模型 : 


class Profile(models.Model): 
user = models.OnToOneField(settings.AUTH_USER_MODEL, primary_key=True) 


这 里 建议 你 明确 的 将 primary key 赋值 为 True ， 以 阻止 类 似 PostgreSQL 这 样 的 数据 库 后 
中 的 并 发 问题 。 剩 下 的 模型 可 以 包含 其 他 的 任何 用 户 详情 ， 比 如 生日 ， 训 好 色彩 ， 等 等 。 


设计 账户 模型 之 时 ， 建 议 所 有 的 账户 详情 字段 都 必须 是 非 空 的 ， 或 者 含有 一 个 默认 值 。 凭 直 
觉 我 们 就 知道 用 户 在 注册 时 是 不 可 能 填写 完 所 有 的 账户 细节 的 。 此 外 ， 我 们 也 要 确保 创建 账 
户 实例 时 ， 信 号 处 理 器 没有 传递 任何 初始 参数 。 


信号 


理论 上 ， 每 一 次 用 户 模 型 实例 的 生成 ， 其 对 应 的 用 户 账户 实例 也 必须 创建 好 。 这 个 操作 通 
使 用 信号 来 完成 。 


E 


例如 ， 我 们 可 以 使 用 下 面 的 信号 处 理 器 侦 听 用 户 模 型 的 post_save 信号 : 


# signals.py 

from django.db.models.signals import post_save 
from django.dispatch import receiver 

from django.conf import settings 

from . import models 


@receiver(post_save, sender-settings.AUTH USER MODEL) 
def create profile handler(sender, instance, created, **kwargs): 
if not created: 
return 
# 仅 在 created 是 最 新 时 才 创 建 账户 对 象 
profile = models.Profile(user=instance) 
profile.save() 


注意 账户 模型 除了 用 户 实例 之 外 并 没有 传递 额外 初始 的 参数 。 


前 面 的 代码 中 ， 初 始 化 信号 代码 并 没有 放 到 特定 的 场所 。 通 常 ， 它 们 在 models.py 中 (这 样 
做 是 不 可 靠 的 ) 导入 或 者 执行 。 不 过 ， 随 着 Django 1.7 的 应 用 载 入 的 重 构 ， 应 用 初始 化 代码 位 
置 的 问题 也 很 好 的 解决 了 。 


首先 ， 为 你 的 应 用 创建 一 个 __init__.py 包 以 引用 应 用 的 ProfileConfig : 


default_app_config = "profile.apps.ProfileConfig" 


接 下 来 是 app.py 中 的 子 类 Profileconfig 方法 ， 可 使 用 ready 方法 配置 信号 : 


# app.py 
from django.apps import AppConfig 


class ProfileConfig(AppConfig): 
name = "profiles" 
verbose_name = "User Profiles" 


def ready(self): 
from . import signals 


随 着 信号 的 配置 ， 对 所 有 的 用 户 来 说 ， 访 问 user.profile 应 该 都 返回 一 个 Profile 对 象 ， 即 
使 是 最 新 创建 的 用 户 也 是 如 此 。 


Admin 


现在 ， 用 户 的 详情 存在 admin 内 的 两 个 不 同 地 方 : 普通 用 户 admin 页 面 中 的 认证 细节 ， 同 一 人 
用 户 的 额外 账户 细节 放 到 了 一 个 独立 账户 的 admin 页 面 ， 这 样 做 显得 非常 麻烦 。 


如 下 ， 为 了 操作 方便 ， 账 户 admin 可 以 通过 定义 一 个 自 定义 的 useradmin RAZ RAMA P 
admin 中 : 


# admin.py 

from django.contrib import admin 

from .models import Profile 

from django.contrib.auth.models import User 


class UserProfileInline(admin.StackedInline): 
model = Profile 


class UserAdmin(admin.UserAdmin) : 
inlines = [UserProfileInline] 


admin.site.unregister (User ) 
admin.site.register(User, UserAdmin) 


多 个 账户 类 型 
假设 在 应 用 中 你 需要 几 种 类 型 的 用 户 账 户 。 这 里 需要 有 一 个 字段 去 跟踪 用 户 使 用 的 是 哪 一 种 
账户 类 型 。 账 户 数据 本 身 需 要 存储 在 独立 的 模型 中 ， 或 者 存储 在 一 个 统一 的 模型 中 。 


建议 使 用 聚合 账户 的 办 法 ， 因 为 它 能 够 改变 账户 类 型 而 不 丢失 账户 细节 ， 兼 具 灵 活性 ， 最 小 
化 复杂 性 。 此 办 法 中 ， 了 账户 模型 包含 一 个 所 有 账户 类 型 的 字段 超 集 。 


例如 ， SuperBook 会 需要 一 个 SuperHero X 类 型 账户 ， 和 一 个 Ordinary ( 非 超 集美 雄 ) 账户 。 
它 可 以 用 一 个 独立 的 统一 账户 模型 实现 : 


class BaseProfile(models.Model): 
USER TYPES = ( 
(0, 'Ordinary'), 
(1, 'SuperHero'), 
) 


user - models.OnToOneField(settings.AUTH USER MODEL, primary key-True) 
user type = models.IntegerField(max length-i, null=True, choices-USER TYPES) 
bio = models.CharField(max length-200, blank=True, null=True) 


def Sit Tum S Ib): 
return "{}:{:.20}".format(self.user, self.bio or "") 


class Meta: 
abstract - True 


class SuperHeroProfile(models.Model): 
origin = models.CharField(max_length=100, blank-True, null-True) 


class Meta: 
abstract - True 


class OrdinaryProfile(models.Model): 
address = models.CharField(max_length=200, blank=True, null-True) 


class Meta: 
abstract = True 


class Profile(SuperHeroProfile, OrdinaryProfile, BaseProfile): 
pass 


我 们 把 账户 细节 组 织 到 多 个 抽检 基 类 再 到 独立 的 关系 中 。 Baseprofile 类 包含 所 有 的 不 关心 用 
户 类 型 的 公共 账户 细节 。 它 也 有 一 个 user type 字段 ， 它 持续 追踪 用 户 的 激活 账户 。 


Stes 类 和 ordinaryProfile 类 分 别 包含 所 有 到 超级 英雄 和 非 超级 英雄 特定 账户 细 
o 最后， 所 有 这 些 基 类 的 profile 类 创 els s 细节 的 超 集 。 


使 用 该 方法 时 要 主要 的 一 
e 所 有 属于 类 的 字段 或 者 它 抽象 基 类 都 必须 是 非 空 的 ， 或 者 有 一 个 默认 值 。 
e 此 方法 或 许 会 因为 每 个 用 户 而 消耗 掉 更 多 的 数据 库 ， 但 是 却 带 来 极 大 的 灵活 性 
e 账户 类 型 的 激活 和 非 激活 字段 都 必须 在 模型 外 部 是 可 管理 的 。 


e 说 到 ， 编 辑 账户 的 表 必 须 显示 合乎 目前 激活 用 户 类 型 的 字段 。 


a L\ ak oy 
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问题 : 模型 会 变 得 庞大 而 且 不 可 管控 。 当 一 个 模型 不 止 实现 一 个 功能 时 ， 测 试 和 维护 也 会 变 
得 困难 。 

解决 方法 : 重 构 出 一 组 相关 方法 到 一 个 专用 的 service TEP ° 


问题 细节 


富 模型 ， 瘦 视图 是 一 个 通常 要 告 诉 Django 新 手 的 格言 o 理论 上 ， 你 的 视图 不 应 该 包含 任何 其 
他 表现 逻辑 。 


可 是 ， 随 着 时 间 的 推移 ， 代 码 段 不 能 够 放 在 任意 地 点 ， 除 非 你 打算 将 它们 放 进 模型 中 。 很 
快 ， 模 型 会 变 成 一 个 代码 的 垃圾 场 。 


下 面 是 模型 可 以 使 用 service 对 象 的 征兆 : 


与 扩展 能 服务 交互 ， 例 如 web 服务 中 ， 检 查 一 个 用 户 具 有 资格 

辅助 任务 不 会 处 理 数据 库 ， 例 如 ， 生 成 一 个 短 链接 ， 或 者 针对 用 户 的 验证 码 。 

牵涉 到 一 个 短命 的 对 象 时 不 会 存在 数据 库 状态 记录 ， 烈 日 ， 创 建 一 个 AJAX 调 用 的 JSON 响 应 。 
对 于 长 时 间 运 行 的 任务 设计 到 了 多 实例 ， 比 如 Celery 任 务 。 


AUNE 


Django 中 的 模型 遵循 着 激活 记录 模式 。 理 论 上 ， 它 们 同时 封装 应 用 罗 即 数据 库 访 问 。 不 过 
要 记得 保持 应 用 逻辑 最 小 化 。 


在 测试 时 ， 如 果 我 们 发 现 没 有 对 数据 库 建 模 的 必要 ， 甚 至 不 会 用 到 数据 库 ， 那 么 我 们 需要 考 
虑 把 分 解 模 型 类 。 建 议 这 种 场合 下 使 用 service 对 象 。 


详解 
服务 对 象 是 封装 一 个 服务 或 者 和 系统 狂 独 的 普通 而 老 昌 的 Python 对 象 (POPOs) 。 它 们 通常 
保存 在 一 个 独立 的 称 为 service.py 或 者 utils.py 的 文件 。 

例如 ， 像 下 面 这 样 ， 检 查 一 个 Web 服务 是 否 作 为 一 个 模型 方法 : 

class Profile(models.Model): 


def is superhero(self): 
url = "http://api.herocheck.com/?q={0}". format ( 
self.user.username 


return webclient.get(url) 


该 方法 可 以 使 用 一 个 服务 对 象 来 重 构 : 


from .services import SuperHeroWebAPI 


def asEsupeqheno(seliy: 
return SuperHeroWebAPI.is superhero(self.user.username) 


现在 服务 对 象 可 以 定义 在 services.py 中 了 : 


API_URL = "http://api.herocheck.com/?q={0}" 
class SuperHeroWebAPI: 

@staticmehtod 

def is hero(username): 


url - API URL.format(username) 
return webclient.get(url) 


多 数 情况 下 ， service 对 象 的 方法 是 无 状态 的 ， 即 ， 它 们 基于 函数 参数 不 使 用 任何 的 类 属性 
来 独立 执行 动作 。 因 此 ， 最 好 明确 地 把 它们 标记 为 静态 方法 (就 像 我 们 对 is_hero 所 做 的 那 
样 ) 。 

可 以 考虑 把 业务 逻辑 和 域名 逻辑 从 模型 迁移 到 服务 对 象 中 去 。 这 样 ， 你 可 以 在 Django 应 用 的 
外 部 很 好 使 用 它们 。 

想象 一 下 ， 由 于 业务 的 原因 ， 要 依据 某 些 用 户 的 名 字 把 这 些 要 成 为 超级 英雄 的 用 户 加 进 黑 名 
单 。 我 们 的 服务 对 象 稍微 改动 以 下 就 可 以 支持 这 个 功能 


class SuperHeroWebAPI: 


@staticmethod 

def is hero(username): 
blacklist = set(["syndrome", "kcka$$", "superfake"]) 
ulr - API URL.format(username) 
return username not in blacklist and webclient.get(url) 


理论 上 ， 服 务 对 象 自 包含 的 。 这 使 它们 多 于 测试 而 不 用 建 模 一 一 即 数据 库 ， 同 时 它们 也 轻松 
地 重复 使 用 。 


o 


Django F > TE PE EIRY en i UI DNA 方式 执行 。 通 常 ， service 对 象 以 Celery 
任务 的 方式 执行 操作 。 这 样 的 任务 可 以 周期 性 地 运行 或 者 延迟 运行 


检索 模式 

本 节 包 含 处 理 模型 特性 的 访问 ， 或 者 对 模型 执行 查询 的 设计 模式 。 
模式 -属性 字段 

问题 : 模型 的 属性 以 方法 实现 。 可 是 ， 这 些 属性 不 应 该 保存 到 数据 库 。 
ARR AR : 对 这 样 的 方法 使 用 特性 装饰 器 。 

问题 详情 


模型 字段 存储 每 个 实例 的 属性 ， 比 如 名 ， 和 姓 ， 生 日 ， 等 等 。 ee o 
是 ， 我 们 也 需要 访问 某 些 派生 的 属性 ， 比 如 一 个 完整 的 名 字 和 ° 


它们 可 以 轻 多 地 计算 数据 库 字段 ， 因 此 它们 不 需要 单独 地 存储 。 在 茶 些 情况 下 ， 它 们 可 以 成 
为 一 个 检查 给 出 的 年 龄 ， 会 员 积分 ， 和 激活 状态 是 否 合格 的 条 件 语句 。 


简洁 明了 的 实现 这 个 方法 是 定义 类 似 下 面 的 get_age 来 实现 : 


class BaseProfile(models.Model): 
birthdate = models.DateField() 


def get_age(self): 
today = datetime.date.today() 
return (today.year - self.birthdate.year) - int( 
(today.month, today.day) < (self.birthdate.month, self.birthdate.day) 
) 


调用 profile.get age() 便 会 通过 计算 调整 过 的 月 和 日 期 所 属 的 那个 年 份 的 不 同 来 返回 用 户 的 


BE o 
不 过 ， 调 用 profile.age 更 具 可 读 性 〈 和 Python 范 ) 。 
详解 
Python 类 可 以 使 用 property 装饰 器 把 函数 当 作 一 个 属性 来 使 用 。 这 样 ，Django 模 型 也 可 以 较 


好 地 利用 它 。 替 换 前 面 那 个 例子 中 的 函数 : 


@property 
def age(self): 


现在 我 们 可 以 用 profile.age KÈ HA P MFR o» Ec WE LER] Hee 


就 像 模型 的 方法 那样 ， 人 问 的 。 你 不 能 够 
在 Queryset 对 象 中 使 用 它 。 例 如 ， 这 么 做 是 无 效 的 ，`Profile.objects.exlude(age__It=18) 。 


它 也 是 一 个 定义 一 个 属性 来 隐藏 类 内 部 细节 的 好 主意 。 这 也 正式 地 称 做 得 墨 已 耳 定 律 。 简 单 
地 说 ， 定 律 声 明 你 应 该 只 访问 自己 的 直属 成 员 或 者 “ 仅 使 用 一 个 点 号 ”。 


例如 ， 最 好 是 定义 一 个 profile.birthyear 属性 ， 而 不 是 访问 profile.birthdate.year 。 这 
样 ， 它 有 助 于 你 隐藏 birthdate 字段 的 内 在 结构 。 


提示 
最 佳 实践 
遵循 得 墨 忒 耳 定 律 ， 并 且 访 问 属 性 时 只 使 用 点 号 


bs 律 的 一 个 不 良 反应 是 它 导 致 在 模型 中 有 多 个 包装 器 属性 被 创建 。 这 使 模型 膨胀 并 让 它们 
得 难以 维护 。 利 用 定律 来 改进 你 的 模型 API， 减 少 模型 间 的 耦合 ， 在 任何 地 方 都 是 可 行 的 。 


缓存 特性 


每 次 我 们 调用 一 个 属性 时 ， 就 要 重新 计算 函数 。 如 果 计 算 的 代价 很 大 ， 我 们 就 想到 了 缓存 结 
果 © 因此 , 下 次 访问 属性 ? 我 们 就 拿 到 | 了 缓存 的 结果 9 


from django.utils.function import cached property 


@cached_ eae 
def full name Med 


及 务 调 用 


vh AR. A Ya /t] 


M p. GE ee firstname, self.lastname) 


缓存 的 值 会 作为 Python 实例 的 一 部 分 而 保存 。 只 要 实例 一 直 存 在 ， 就 会 得 到 同样 的 返回 值 


就 保护 性 机 制 来 说 ， 你 或 许 想 要 强制 执行 代价 高 兄 的 操作 以 确保 过 期 的 值 不 会 返回 。 这 样 ， 
设置 一 个 cached=False 这 样 的 关键 字 参 数 以 阻止 返回 缓存 的 值 。 


ak ` > wy Jt 

模式 -定制 模型 管理 器 

问题 : 某 些 模型 的 定义 的 查询 被 重复 地 访问 ， 整 个 代码 也 就 违反 了 DRY 原 则 。 
解决 方案 : 通过 定义 自 定 义 的 管理 器 ， 使 常见 的 查询 拥有 意义 的 名 称 。 
问题 细节 


i0 1 E objects 的 管理 器 。 调 用 objects.all() 会 返回 数据 
库 中 的 这 个 模型 的 所 有 条 目 。 ， 我 们 只 对 所 有 条 目的 子 集 感 兴趣 。 


我 们 应 用 多 种 过 滤器 以 找 出 所 需 的 条 目 组 。 挑 选 它们 的 原则 常常 是 我 们 的 核心 业务 逻辑 。 例 
如 ， 我 们 发 现 使 用 下 面 的 代码 可 以 通过 public 访 问 文章 : 


public = Posts.objects.filter(privacy="public") 


这 个 标准 在 未 来 或 许 会 改变 。 我 们 或 许 也 想 要 检查 文章 是 否 标记 为 编辑 。 这 个 改变 或 许 如 
wh : 


public = Posts.objects.filter(privacy=POST_PRIVACY.Public, draft=Flase) 


RAAE ERR ARAM BAALE 9 RAER o RUBUS ET IL 
这 样 常见 地 查询 而 无 需 “ 自 我 重复 ”。 


Querysets 是 一 个 功能 极其 强大 的 抽象 概念 。 它 们 仅 在 需要 时 才 进 行情 性 查询 。 因 此 ， 
链 式 方法 〈 一 个 顺畅 的 接口 ) 构建 长 的 Querysets 并 不 影响 性 能 。 


事实 上 ， 随 着 更 多 的 过 滤 的 应 用 反倒 会 使 结果 数据 集合 得 以 缩减 。 这 样 做 的 话 通常 能 够 减少 
内 存 消耗 。 
模型 管理 器 是 一 个 模型 获取 自身 Queryset 对 象 的 便利 接口 。 换 多 话 来 讲 ， 它 们 有 助 于 你 使 用 
Django 的 ORM 访 问 下 层 的 数据 库 。 事 实 上 ， Queryset 对 象 上 管理 器 以 一 个 非常 简单 的 包装 
器 实现 。 请 注意 相同 到 接口 : 

>>> Post.objects.filter(posted_by__username="a") 

[<Post:a: Hello World»* <Post:a: This is Private!>] 


>>> Post.objects.get_queryset().filter(posted_by__username="a" ) 
[<Post:a: Hello World>, <Post:a: This is Private!>] 


软 认 的 管理 器 由 Django 创 建 ， objects 有 多 种 方法 返回 Queryset ， 比 如 all ， filter 或 
者 exclude 。 不 过 ， 它 们 仅仅 是 生成 了 一 个 到 数据 库 的 低级 API 。 


定制 管理 器 用 于 创建 特定 的 域名 ， 高 级 API。 这 样 不 仅 更 具 可 读 性 ， 而 且 通 过 实现 细节 减轻 所 
受到 的 影响 。 因 此 ， 你 就 能 够 利用 高 级 抽象 来 严格 的 对 域名 建 模 了 。 


如 下 ， 前 面 的 公开 文章 例子 就 可 以 很 轻松 地 转换 为 一 个 定制 的 管理 器 : 


# managers.py 
from dana db.models.query import Queryset 


class PostQuerySet(QuerySet): 
def public posts(self): 
return self.filter(privacy="public") 


PostManager - PostQuerySet.as manager 


这 是 一 个 在 Django 1.7 中 从 Queryset 对 象 创 建 定 制 管理 器 的 捷径 。 不 像 前 面 的 其 他 方法 ， 
个 PostManager 对 象 像 默 认 的 objects 管理 器 一 样 是 可 链 式 的 。 


如 下 所 示 ， 有 些 时 候 ， 使 用 定制 的 管理 器 替换 去 默认 的 objects 管理 器 也 是 可 行 的 : 


from .managers import PostManager 
class Post(Postable): 


objects = PostManager() 


这 样 ， 访 问 public_posts 就 相当 简单 了 : 


public = Post.objects.public_posts() 


因为 返回 值 是 一 个 QuerySet ^? 它们 可 以 更 进一步 过 滤 : 


public_apology = Post.objects.public_posts().filter( 
message_startwith = "Sorry" 


) 


QuerySets 由 多 个 值得 注意 的 属性 。 在 下 一 节 里 ， 我 们 可 以 看 到 一 些 含有 混合 queryset 的 常 
见地 模式 。 


Querysets 的 组 合 动作 


事实 上 ， 对 于 它们 的 名 字 (或 者 是 他 们 名 字 的 后 一 半 ) ， Querysets 支持 多 组 (数学 上 的 ) 
操作 。 为 了 说 明 ， 考 虑 包含 用 户 对 象 的 两 个 QuerySets 

>>> q1 = User.objects.filter(username_in["a", "b", "c"]) 

[<User:a>, <User:b>, <User:c>] 


>>> q2 = User.objects.filter(username  in["c", "d"]) 
[<User:c>, <User:d>] 


对 于 一 些 组 合 操作 可 以 执行 以 下 动作 : 


e Union 一 交集 : 合并 ， 移 除 重复 动作 。 使 用 qi | a2 获得 


[ <User: a>, <User: b>, <User: c>, <User: d> ] 
e Intersection—#% : 找 出 公共 项 。 使 用 qi | q2 RAT] 


e Difference 一 补 集 : 从 第 一 个 集合 中 移 除 同时 包含 在 第 二 个 集合 中 的 元 素 。 该 操作 并 不 按 
逻辑 来 。 改 用 `q1.exlude(pk。_in=q2) 获 得 【, J 


同样 的 操作 我 们 也 可 以 用 Q 对 象 来 完成 : 


from django.db.models import Q 

# Union 交集 

>>> User.objects.filter(Q(username_in["a", "b", "c"]) | Q(username__in=["c", "d"])) 
[ «User: a», «User: b», «User: c», «User: d»'] 

# Intersection JF 

>>> User.objects.filter(Q(username_in["a", "b", "c"]) & Q(username__in=["c", "d"])) 
[xUser: c>] 

# Difference 补 集 


>>> User.objects.filter(Q(username in-["a", "b", "c"]) & ~Q(username__in=["c", "d"])) 
[<User: a», «User: b>] 


注意 执行 动作 所 使 用 & (de) 以 及 ~ (FE) 的 不 同 。 Q 对 象 是 非常 强大 的 ， 它 可 以 用 来 
构建 非常 复杂 的 查询 。 

不 过 ， set 虽 相 似 但 却 不 完美 。 QuerySets 不 像 数 学 上 的 集合 那样 按照 顺序 来 。 因 此 ， 就 这 
方面 来 说 它们 更 接近 于 Python 的 列表 数据 结构 。 


链接 多 个 Querysets 


目前 为 止 ， 我 们 已 经 合并 了 属于 相同 基 类 的 同类 型 Querysets 。 可 是 ， 我 们 或 许 需 要 合并 来 
自 不 同 模型 的 Questsets ， 并 对 它们 执行 操作 。 


例如 ， 一 个 用 户 的 活动 时 间 表 包 含 了 它们 自身 所 有 的 按照 反 向 时 间 顺序 所 发 布 的 文章 和 评 
论 。 之 前 混合 Querysets 方法 是 不 会 起 作用 的 。 一 个 很 天 监 的 做 法 是 把 它们 转换 到 列表 ， 连 
接 并 排列 这 个 列表 : 


>>> recent = list(posts)+list(comments) 
>>> sorted(recent, key=lambda e: e.modified, reverse=True)[:3] 
[<Post: user: Posti», «Comment: user: Commenti», «Post: user: Post0>] 


不 幸 的 是 ， 这 个 操作 已 经 对 惰性 的 querysets 对 象 求 值 了 。 两 个 列表 的 内 存 使 用 算 在 一 起 可 
能 很 大 内 存 开 销 。 另 外 ， 转 换 一 个 庞大 的 Querysets 到 列表 是 很 慢 很 慢 的 。 


Weide) Se iE 失 代 器 减少 内 存 消 耗 。 如 下 ， 使 用 itertools.chain 方法 合并 多 


个 QuerySets : 


>>> from itertools import chain 
>>> recent = chain(posts, comments) 
>>> sorted(recent, key=lambda e: e.modified, reverse=True)[:3] 


只 要 计算 QuerySets ， 连接 数据 的 开销 都 会 非常 搞 。 因 此， 重要 的 是 ， 尽 可 能 长 的 仅 有 的 不 
对 Querysets 求 值 的 操作 时 间 。 


日 
提示 
尽量 延长 querysets 不 求 值 的 时 间 。 


迁移 


迁移 让 你 改变 模型 时 更 有 信心 。 说 的 Django 1.7， 迁 移 已 经 是 开发 流程 中 基本 的 易于 使 用 的 一 


部 分 了 。 


新 的 基本 流程 如 下 : 


1， 第 一 次 定义 模型 类 的 话 ， 你 需要 运行 : 
python manage.py makemigrations <app_label> 


2. 这 将 在 `“app/migrations 人 文件 夹 内 创建 迁移 脚本 。 
在 同样 的 (开发 ) 环境 中 运行 以 下 命令 : 


python manage.py migrate <app_label> 
3. 这 将 对 数据 库 应 用 模型 变更 。 有 时 候 ， 遇 到 的 问题 有 ， 处 理 默 认 值 ， 重 命名 ， 等 等 。 
4. 普及 迁移 脚本 到 其 他 的 环境 。 通 常 ， 你 的 版 本 控制 工具 ， 例 如 ，Git， 会 小 心 处理 这 事 。 当 最 新 的 源 释 出 时 ， 新 的 迁 
5. 在 这 些 环境 中 运行 下 面 的 命令 以 应 用 模型 的 改变 : 

python manage.py migarte <app_label> 


不 论 何 时 要 将 变更 应 用 到 模型 ， 请 重复 以 上 1-5 步 又 。 
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如 果 你 在 命令 里 忽略 了 app 标 签 ，Django 会 在 每 一 个 app 中 发 现 未 应 用 的 变更 并 迁移 它们 。 


Fide ER a a Django 开 发 的 基础 。 本 章 ， 我 们 学 习 了 使 用 模型 时 
多 个 常见 模式 。 每 个 例子 中 ， 我 们 都 见 到 了 建议 方案 的 作用 ， 以 及 多 种 折衷 方案 。 


这 下 一 章 ， 我 们 会 用 视图 和 URL 配 置 来 验证 所 遇 到 的 常见 设计 模式 。 


第 四 章 - 视 图 和 URL 


本 章 ， 我 们 会 讨论 以 下 话题 : 
e 基于 类 的 和 基于 函数 的 视图 
e Mixins 
e 装饰 器 


e 常见 视图 模式 


e 设计 URL 
顶层 的 视图 
Django 中 ， TE 是 可 以 调用 的 ， 它 接受 请 求 并 返回 响应 。 通 常 它 是 一 个 函数 或 者 是 一 个 拥 


有 as view() 这 类 特殊 方法 的 类 。 


这 两 种 情况 下 ， 我 们 创建 一 个 普通 的 接受 HTTPRequest 作为 自己 的 第 一 个 参数 并 返回 一 
个 HTTPResponse 的 Python 函数 。 URLConf 也 可 以 对 这 个 函数 传递 额外 的 参数 。 这 些 参 数 由 
URL 部 分 捕捉 到 ， 或 者 是 设置 了 默认 值 。 


里 是 简单 视图 的 例子 


# In views.py 
from django.http import HttpResponse 


def hello_fn(request, name="World"): 
return HttpResponse("Hellp {}!".format(name) ) 


两 行 视图 函数 非常 简单 和 好 理解 。 目 前 我 们 还 没有 用 Leinen ui Rn o 例如， 
pee 查看 GET/POST 参数 ，URI 路 径 ， 或 者 REMOTE_ADDR 这 样 的 HTTP 头 部 ， 验证 请 求 可 以 
我 们 更 好 地 理解 所 调用 视图 中 的 上 下 文 。 


URLConf 中 所 对 应 的 行 如 下 : 


# In urls.py 
url(r'^hello-fn/(?P<name>\w+)/$', views.hello fn), 
url(r'^hello fn/$', views.hello fn), 


我 们 重复 使 用 相同 的 视图 以 个 URL 模 式 。 第 一 个 模式 获得 了 一 个 name 参 数 。 第 二 个 模 
式 没 有 从 URL 获 得 任何 参数 ， 这 个 例子 中 视图 会 使 用 默认 的 world 名 字 。 


让 视图 变 得 更 高 级 


基于 类 的 视图 在 Django 1.4 中 被 引入 。 下 面 是 之 前 的 视图 在 用 了 同等 功能 的 基于 类 的 视图 重 写 
之 后 的 样子 : 


from django.views.generic import View 


class HelloView(View): 
def get(self, request, name="World"): 
return HttpResponse("Hello {}!".format(name) ) 


同样 地 ， 对 应 的 uRLConf 也 有 两 行 ， 一 如 下 面 命令 所 示 : 


# In urls.py 
url(r'^hello-cl/(?P«name»Nw*)/$', views.HelloView.as view()), 
url(r'^hello-cl/$', views.HelloView.as view()), 


这 个 view 类 和 我 们 之 前 的 视图 函数 之 间 有 多 个 有 趣 的 不 同 点 。 最 明显 的 一 点 就 是 我 们 需要 定 
义 一 个 类 。 接 着 ， 我 们 明确 地 定义 了 我 们 唯一 要 处 理 的 cet 请 求 。 之 前 的 视图 

对 cet ， post 做 出 了 同样 的 响应 ， 或 者 其 他 的 HTTP 词 汇 ， 下 面 是 在 Django shell 中 使 用 测 
试 客户 端 : 


>>> from django.test import Client 

>>> c = Client() 

>>> c.get("http://0.0.0.0:8000/hello-fn/").content 
b'Hello World!' 

>>> c.post("http://0.0.0.0:8000/hello-fn/").content 
b'Hello World!' 

>>> c.get("http://0.0.0.0:8000/hello-cl/").content 
b'Hello World!' 

>>> c.post("http://0.0.0.0:8000/hello-cl/").content 
Don 


就 安全 和 可 维护 性 的 角度 来 说 ， 还 是 显 式 更 好 一 些 。 


当 你 需要 定制 视图 的 时 候 ， 使 用 类 的 好 处 才 会 清晰 的 体现 出 来 。 就 是 说 ， 你 需要 改变 所 问候 
的 内 容 。 你 可 以 编写 一 个 任意 类 型 的 普通 视图 类 ， 并 派生 出 所 指定 的 问候 类 : 


class CreetView(View): 
greeting = "Hello {}!" 
default name - "World" 
def geEr(seli request. ““kwangs)!: 
name = kwargs.pop("name", self.default_name) 
return HttpResponse(self.greeting. format (name) ) 


class SuperVillianView(GreetView) : 
greeting = "We are the future, {}. Not them." 
default_name = "my friend" 


现在 ， URLConf 可 以 引用 派生 的 类 : 


Django 设计 模式 与 最 佳 实践 


# In urls.py 
url(r'Ahello-su/(?<name>\w+)/$', views.SuperVillianView.as view()), 
url(r'^hello-su/$', views.SuperVillianView.as view()), 


按照 类 似 的 方式 来 定制 视图 函数 不 可 行 时 ， 你 需要 添加 多 个 有 默认 值 的 关键 字 参 数 。 这 样 做 
很 快 会 变 得 不 可 控制 。 这 就 是 为 什么 通用 视图 从 视图 函数 迁移 到 基于 类 的 视图 的 原因 。 


Django Unchained 


After spending 2 weeks hunting for good Django developers, Steve started to think out 
of the box. Noticing the tremendous success of their recent hackathon, he and Hart 
organized a Django Unchained contest at S.H.I.M. The rules were simple—build one 
web application a day. It could be a simple one but you cannot skip a day or break the 
chain. Whoever creates the longest chain, wins. 


The winner—Brad Zanni was a real surprise. Being a traditional designer with hardly 
any programming background, he had once attended week-long Django training just for 
kicks. He managed to create an unbroken chain of 21 Django sites, mostly from 
scratch. 


The very next day, Steve scheduled a 10 o' clock meeting with him at his office. Though 
Brad didn't know it, it was going to be his recruitment interview. At the scheduled time, 
there was a soft knock and a lean bearded guy in his late twenties stepped in. 


As they talked, Brad made no pretense of the fact that he was not a programmer. In 
fact, there was no pretense to him at all. Peering through his thick-rimmed glasses with 
calm blue eyes, he explained that his secret was quite simple—get inspired and then 
focus. He used to start each day with a simple wireframe. He would then create an 
empty Django project with a Twitter bootstrap template. He found Django's generic 
class-based views a great way to create views with hardly any code. Sometimes, he 
would use a mixin or two from Django-braces. He also loved the admin interface for 
adding data on the go. 


His favorite project was Labyrinth—a Honeypot disguised as a baseball forum. He even 
managed to trap a few surveillance bots hunting for vulnerable sites. When Steve 
explained about the SuperBook project, he was more than happy to accept the offer. 
The idea of creating an interstellar social network truly fascinated him. 


With a little more digging around, Steve was able to find half a dozen more interesting 
profiles like Brad within S.H.I.M. He learnt that rather that looking outside he should 
have searched within the organization in the first place. 


基于 类 的 通用 视图 
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通常 ， 基 于 类 的 通用 视图 为 了 能 更 好 地 重复 使 用 代码 ， 便 利用 以 面向 对 象 的 方法 〈 模 板 方法 
模式 ) 实现 的 视图 。 我 讨厌 术语 generic views 。 我 更 乐意 把 它们 叫做 stock view 。 就 像 所 
储备 的 照片 ， 你 可 以 按照 自己 的 常见 需要 对 它们 做 出 轻微 的 调整 。 

通用 视图 的 产生 是 因为 Django 开 发 者 发 现 他 们 在 每 一 个 项 目 中 都 在 重复 构建 同类 型 的 视图 。 
几乎 每 个 项 目 都 需要 有 一 个 页 面 来 显示 一 个 对 象 的 列表 ( List view ) ， 或 者 一 个 对 象 的 具 
体内 容 ( detail view ) ， 有 或 者 是 一 个 用 来 创建 对 象 的 表单 。 依 照 DRY 精 神 ， 这 些 可 重复 使 
用 的 视图 被 Django 打包 在 一 起 。 


给 出 Django 1.7 中 通用 视图 速 查 表格 : 


= 


K Jn 


类 型 类 名 称 描述 


基本 |Vew| 这 是 所 有 视图 的 父 类 。 它 执行 派 忠和 清醒 检测 。 KA Template View| ts ARK © A 
露 URLConf 的 关键 字 到 上 下 文 。 基 本 |ReaoirectView| 对 任意 GET 请 求 做 出 重 定 向 。 Fi 

表 |ListView| 传 递 任意 可 和 迭代 的 项 ， 比 如 9Ueryset。 详细 |DetailView| 传 递 基于 来 自 URLConf 的 
pK 或 者 slug。 编辑 |FormView| 传 递 并 处 理 表 单 编辑 |CreateView| 传 递 并 处 理 生成 新 对 象 的 表 
单 。 编辑 |UpdateView| 传 递 并 处 理 更 新 对 象 的 表单 。 编辑 |DeljeteView| 传 递 并 处 理 删 除 对 象 
的 表单 。 日 期 |ArchivelIndexView| 传 递 含有 日 期 字段 的 对 象 列 表 ， 并 把 最 新 的 日 期 放 在 最 前 
面 。 日 期 |YearArchiveView| 传 递 基于 URLConf 中 所 给 定 的 year 的 对 象 列 表 日 

33 |MonthArchive View|f* 3& X T yearfe month*' t $.7| € » 日 期 |WeekArchiveView| 传 递 基于 
year 和 Wweek 数 的 对 象 列表 。 日 期 |DayArchiveView| 传 递 基于 year，month 和 day 的 对 象 列表 。 
日 en rae 当日 日 期 的 对 象 列 表 。 日 期 |DateDetailViewl| 传 递 一 个 基于 
year，month， 和 day， 通 过 自身 的 pk 或 者 slug 来 区 分 的 对 象 。 


我 们 已 经 提 过 类 似 BaseDetailView 这 样 的 基 类 ， 或 是 singleobjectMixin 这 样 的 mixins。 它 们 
设计 成 父 类 。 多 数 情况 下 ， 你 不 会 直接 地 运用 它们 。 


大 多 数 人 对 基于 类 的 视图 和 基于 类 的 通用 视图 感到 迷惑 。 因 为 它们 的 名 称 相 似 ， 但 是 它们 并 
非 是 同一 个 东西 。 这 导致 一 些 令 人 担心 的 误会 : 
* 通 用 视图 仅仅 是 Django 的 一 组 集合 * : 谢 天 谢 地 ， 这 是 错 的 。 在 基于 类 的 通用 视图 中 是 没有 什么 特殊 魔法 的 。 
它们 省 去 了 你 创建 自己 的 一 组 基于 类 的 通用 视图 的 麻烦 。 你 也 可 以 使 用 类 似 `django-vanilla-views ` 这 样 的 第 三 方 库 
* 基 于 类 的 视图 必须 总 是 从 一 个 通用 视图 中 派生 * : 同样 地 ， 通 用 视图 类 也 没有 什么 魔法 。 尽 管 ， 有 百 分 之 九 十 的 时 间 ， 你 


了 — E 





视图 mixin 


Mixin 是 在 基于 类 的 视图 中 按照 DRY 原 则 写 代码 的 精 散 所 在 。 就 像 模 型 mixin 一 样 ， 视 图 mixin 
得 益 于 Python 的 多 重 继承 ， 因 此 它 可 以 很 好 的 重复 使 用 大 部 分 的 功能 。 在 Python 3 中 它们 常 
是 无 父 类 的 类 (或 者 是 在 Python 2 中 新 格式 的 类 都 派生 自 object ) ° 


Mixin 会 在 定义 过 的 地 方 拦截 视图 的 处 理 过 程 。 例 如 ， 大 多 数 的 通用 视图 使 
用 get context data 设置 上 下 文字 典 。 它 是 一 个 插入 额外 上 下 文 的 好 地 方 ， 比 如 一 个 用 户 可 
以 查看 所 有 指向 发 布 文章 的 feed 变量 ， 一 如 下 面 命令 所 示 : 


class FeedMixin(object): 
def get_context_data(self, **kwargs): 
context = super().get context data(**kwargs) 
context["feed"] = models.Post.objects.viewable posts(self.request.user) 
return context 


首先 get context data 方法 在 基 类 中 调用 所 有 与 自己 同名 的 方法 来 生成 上 下 文 。 接 下 来 ， 他 
用 feed 变量 更 新 上 下 文字 典 。 


现在 ， 在 基 类 的 列表 中 ， 这 个 mixin 通 过 包含 它 就 可 以 很 容易 地 来 添加 用 户 的 订阅 。 这 就 是 
说 ， 如 果 SuperBook 需 要 有 一 个 发 布 新 文章 便 可 被 订阅 的 表单 的 典型 社交 网 络 主页 ， 你 可 以 
像 下 面 这 样 使 用 这 个 mixin : 


class MyFeed(FeedMixin, generic.CreateView): 
model = models.Post 
template name = "myfeed.html" 
success url - reverse lazy("my feed") 


一 个 写 的 很 好 的 mixin 比 需要 非常 高 的 要 求 。 它 应 该 在 多 数 情况 下 都 可 以 被 灵活 运用 。 在 前 面 
的 例子 中 ， FeedMixin 会 重 写 派生 类 中 的 feed 上 下 文 变 量 。 如 果 父 类 要 把 feed MELFI 
变量 ， 它 可 以 通过 包含 这 个 mixin 发 挥 作用 。 因 此 ， 在 使 用 mixin 之 前 ， 你 需要 检查 mixin 的 源 
代码 以 及 其 他 的 类 ， 以 确保 没有 方法 或 者 上 下 文 变量 的 冲突 。 


mixins 的 顺序 
你 或 许 见 过 有 多 个 mixins 的 代码 : 


class ComplexView(MyMixin, YourMixin, AccesMixin, DetailView): 


It can get quite tricky to figure out the order to list the base classes. Like most things in 
Django, the normal rules of Python apply. Python's Method Resolution Order (MRO) 
determines how they should be arranged. 


要 找到 列 出 基 类 的 顺序 是 非常 棘手 的 一 件 事 。 就 像 Django 中 的 大 多 数 情 形 一 样 ， 要 用 到 就 是 
Python 的 基本 规则 。Python 的 方法 解析 顺序 决定 了 它们 该 如 何 被 排列 出 来 。 


In a nutshell, mixins come first and base classes come last. The more specialied the 
parent class is, the more it moves to the left. In practice, this is the only rule you will need to 
remember. 


简单 来 说 就 是 ， 把 mixin 放 在 最 前 面 ， 而 基 类 放 在 最 后 面 。 如 果 有 更 多 的 父 类 ， 这 些 父 类 都 会 
被 放 到 左边 。 


To understand why this works, consider the following simple example: 


class 
def do(self): 
print("A") 
class B: 
def do(self): 
print("B") 


class BA(B, A): 
pass 


class AB(A, B): 
pass 


BA().do() # Prints B 
ABL) do() 4 Prints 4 


As you would expect, if B is mentioned before A in the list of base classes, then B's method 
gets called and vice versa. 


Now imagine A is a base class such as CreateView and B is a mixin such as FeedMixin. The 
mixin is an enhancement over the basic functionality of the base class. Hence, the ixin 

code should act first and in turn, call the base method if needed. So, the correct order is BA 
ixins first, base last. 


The order in which base classes are called can be determined by checking the — mro 
attribute of the class: 


>>> AB. mro . 
(main .AB, main  .A, main  .B, object) 





So, if AB calls super() , first A gets called; then, As super() will call B, and so on. 


Python's MRO usually follows a depthfirst, lefttoright order to select a method in the c 


A+ Be 
装饰 器 
Before class-based views, decorators were the only way to change the behavior of function- 


based views. Being wrappers around a function, they cannot change the inner working of the 
view, and thus effectively treat them as black boxes. 


A decorator is function that takes a function and returns the decorated function. onfused? 
There is soe syntactic sugar to help you. se the annotation notation @, as shown in the 
following login required decorator example: 


@login_required 
def simple_view(request): 
return HttpResponse() 


The following code is exactly same as above: 


def simple 2w( request): 
enm  HttpResponse() 
simple view - login required(simple view) 


Since login required wraps around the view, a wrapper function gets the control first. If the 

user was not logged in, then it redirects to settings.LoerN uRL . Otherwise, it executes 
simple view as if it did not exist. Decorators are less exible than ixins. However, they 

are sipler. You can use both decorators and mixins in Django. In fact, many mixins are 

implemented with decorators. 


` ak ` 

视图 模式 
Let's take a look at some common design patterns seen in designing views. 
模式 -访问 控制 视图 


问题 : 页 面 需要 基于 用 户 是 否 登 录 ， 是 否 是 站 点 成 员 ， 或 者 其 他 的 任何 条 件 ， 按 照 条 件 访 
B o 


解决 方法 : 使 用 mixins 或 者 装饰 器 控制 到 视图 的 访问 。 

问题 细节 

大 多 数 的 网 站 都 有 当 你 登录 才能 访问 的 页 面 。 另 外 的 一 些 页 面 可 以 被 匿名 访问 或 者 普通 游客 
访问 。 如 果 一 个 匿名 访客 视图 访问 一 个 面向 已 登录 用 户 的 页 面 ， 它们 会 被 路 由 到 登录 页 面 。 
理论 上 ， 在 登录 后 ， 他 们 应 该 被 路 由 回 第 一 次 想 要 见 到 的 页 面 。 

方案 详情 

有 两 个 控制 到 一 个 视图 的 访问 方法 : 


1. 通过 对 基于 函数 视图 或 者 基于 类 视图 使 用 一 个 装饰 器 实现 控制 : 


@login_required(MyView.as_view()) 


2. 通过 覆盖 mixin 的 类 视图 的 `dispatch ` 方 法 实现 控制 : 


class LoginRequiredMixin: 
@method_decorator(login_required) 
def dispatch(self, request, *args, **kwargs): 
return super().dispatch(request, *args, **kwargs) 


KERMAMKEZR SES o LAW GWU RERET : 


class LoginRequiredMixin: 
def dispatch(self, request, *args, **kwargs): 
if not request.user.is authenticated(): 
raise PermissionDenied 
return super().dispatch(request, *args, **kwargs) 


3 FUÉ PermissionDenied 抛 出 时 ，Dijango 会 在 根 目 录 中 显示 403. html 模板 ， 如 果 模 板 不 存 
在 ， 就 会 出 现 “403 Forbidden" 9t @ » 


这 里 使 用 它们 控制 到 登录 和 匿名 访问 的 视图 : 


from braces.views import LoginRequiredMixin, AnonymousRequiredMixin 
class UserProfileView(LoginRequiredMixin, DetailView): 
# This view will be seen only if you are logged-in 
pass 
class LoginFormView(AnonymousRequiredMixin, FormView): 
# This view will NOT be seen if you are loggedin 
authenticated_redirect_url = "/feed" 


Django 中 站 点 成 员 是 使 用 设置 在 用 户 模型 中 的 is statt 标识 的 用 户 。 
同样 地 ， 你 可 以 使 用 称 做 UserPassesTestMixin 的 django-braces mixin : 


from braces.views import UserPassesTestMixin 


class SomeStaffView(UserPassesTestMixin, TemplateView): 
de steStaiunciiseli muse: 
return user.is_staff 


你 也 可 以 创建 执行 特定 检查 的 mixins， 比 如 对 象 是 否 被 原作 者 或 者 其 他 人 (使 用 登录 用 户 比 
对 ) 编辑 : 


class CheckOwnerMixin: 
# 被 用 于 派生 自 Single0bjectMixin 的 类 
def get_object(self, queryset=None): 
obj = super().get object(queryset) 
if not obj.owner == self.request.user: 
raise PermissionDenied 
return obj 


模式 -上 下 文 加 强 器 


问题 : 多 个 基于 类 的 通用 视图 需要 相同 的 上 下 文 变量 。 


用 
解决 方法 : 创建 一 个 设置 为 共享 上 下 文 变量 的 mixin 。 


问题 细节 


Django templates can only show variables that are present in its context dictionary. 
However, sites need the same information in several pages. For instance, a sidebar showing 
the recent posts in your feed might be needed in several views. 


However, if we use a generic class-based view, we would typically have a limited set of 
context variables related to a specific odel. etting the sae context variable in each view 
is not DRY. 


方案 详情 


Most generic class-based views are derived from ContextMixin. It provides the 
get_context_data method, which most classes override, to add their own context variables. 
While overriding this method, as a best practice, you will need to call get_context_data of the 
superclass first and then add or override your context variables. 


We can abstract this in the form of a mixin, as we have seen before: 


class FeedMixin(object): 
def get_contex ata(self, **kwargs): 

context = super().get context data(**kwargs) 
context["feed"] - models.Post.objects.viewable posts(self. 

request.user) 
return context 


We can add this mixin to our views and use the added context variables in our teplates. 
otice that we are using the odel anager defined in Chapter 3, Models, to filter the posts. 


A more general solution is to use StaticContextMixin from django-braces for static-context 
variables. For example, we can add an additional context variable latest profile that contains 
the latest user to join the site: 


class CtxView(StaticContextMixin, generic.TemplateView): 
template name = "ctx.html" 
static context = ("latest profile": Profile.objects.latest('pk')) 


Here, static context means anything that is unchanged from a request to request. In that 
sense, you can mention QuerySets as well. However, our feed context variable needs 
self.request.user to retrieve the user's viewable posts. Hence, it cannot be included as a 
static context here. 


ak ` 
模式 -服务 
问题 : Information from your website is often scraped and processed by other applications. 


解决 方法 : 创建 返回 机 器 友好 的 格式 的 轻 量 的 服务 ， 比 如 JSON 或 者 XML ° 


问题 细节 


We often forget that websites are not just used by huans. significant percentage of web 
traffic coes fro other progras like crawlers, bots, or scrapers. Sometimes, you will need 
to write such programs yourself to extract information from another website. 


Generally, pages designed for human consumption are cumbersome for mechanical 
extraction. HTML pages have information surrounded by markup, requiring extensive 
cleanup. Sometimes, information will be scattered, needing extensive data collation and 
transformation. 


achine interface would be ideal in such situations. You can not only reduce the hassle of 
extracting information but also enable the creation of mashups. The longevity of an 
application would be greatly increased if its functionality is exposed in a machine-friendly 
manner. 


方案 详情 


Service-oriented architecture (SOA) has popularized the concept of a service. A service is 
a distinct piece of functionality exposed to other applications as a service. For example， 
Twitter provides a service that returns the most recent public statuses. 


A service has to follow certain basic principles: 


* Statelessness: This avoids the internal state by externalizing state information 
* Loosely coupled: This has fewer dependencies and a minimum of assumptions 
* Composable: This should be easy to reuse and combine with other services 


In Django, you can create a basic service without any third-party packages. Instead of 
returning HTML, you can return the serialized data in the JSON format. This form of a 
service is usually called a web Application Programming Interface (API). 


For exaple, we can create a siple service that returns five recent public posts from 
SuperBook as follows: 





get , request, *args, **kwargs): 

msgs = models.Post.objects.public_posts().values( 
"posted by id", "message")[:5] 

return HttpResponse(list(msgs), content type-'"application/json") 


For a more reusable implementation, you can use the JsonResponseMixin class from 
django-braces to return JSON using its render json response method: 


from braces.views import JSONResponseMixin 
class PublicPostJSONView(JSONResponseMixin, generic.View): 
def get(self, request, *args, **kwargs): 
msgs - models.Post.objects.public posts().values("posted by id", "message")[:5 
return self.render json response(list(msgs)) 


4 — OW 


If we try to retrieve this view, we will get a JSON string rather than an HTML response: 


>>> from django.test import Client 

>>> Client().get("http://0.0.0.0:8000/public/").content 

bespostedsbysiduu23 «messages: eol 
["posted by id": 13, "message": "Feeling happy"), 


Note that we cannot pass the QuerySet method directly to render the JSON response. It has 
to be a list, dictionary, or any other basic Python built-in data type recognized by the JSON 
serializer. 


Of course, you will need to use a package such as Django REST framework if you need to 
build anything more complex than this simple API. Django REST framework takes care of 
serializing (and deserializing) QuerySets, authentication, generating a web-browsable API, 
and many other features essential to create a robust and fulledged PI. 


设计 URL 


Django has one of the ost exible RL schees aong web fraeworks. Basically, there 
is no iplied RL schee. You can explicitly define any RL scheme you like using 
appropriate regular expressions. 


However, as superheroes love to say 一 "With great power comes great responsibility. You 
cannot get away with a sloppy RL design any more. 


URLs used to be ugly because they were considered to be ignored by users. Back in the 90s 
when portals used to be popular, the common assumption was that your users will come 
through the front door, that is, the home page. They will navigate to the other pages of the 
site by clicking on links. 


Search engines have changed all that. According to a 2013 research report, nearly half (47 
percent) of all visits originate from a search engine. This means that any page in your 
website, depending on the search relevance and popularity can be the first page your user 
sees. ny RL can be the front door. 


More importantly, Browsing 101 taught us security. Don't click on a blue link in the wild, we 
warn beginners. Read the RL first. Is it really your bank's RL or a site trying to phish your 
login details? 


Today, URLs have become part of the user interface. They are seen, copied, shared, and 
even edited. Make them look good and understandable from a glance. No more eye sores 
such as: 


http://example.com/gallery/default .asp?sid=9DF4BC0280DF12D3ACB6009027 
1E26A8&command=commnt form 


Short and meaningful URLs are not only appreciated by users but also by search engines. 
URLs that are long and have less relevance to the content adversely affect your site's 
search engine rankings. 


Finally, as implied by the maxim "Cool URIs don't change," you should try to maintain your 
URL structure over time. Even if your website is completely redesigned, your old links should 
still work. Django makes it easy to ensure that this is so. 


Before we delve into the details of designing URLs, we need to understand the structure of a 
URL. 


URL A? 2] 


Technically, URLs belong to a ore general faily of identifiers called Uniform Resource 
Identifiers (URIs). Hence, a URL has the same structure as a URI. 


A URI is composed of several parts: 


URI = Scheme + Net Location + Path + Query + Fragment 


For example, a URI (http://dev.example.com:80/gallery/ videos?id=217#comments) can be 
deconstructed in Python using the urlparse function: 


>>> from urllib.parse import urlparse 

>>> urlparse("http://dev.example.com:80/gallery/videos?id=217#comments" ) 
ParseResult(scheme='http', netloc='dev.example.com:80', path='/gallery/ 
videos', params='', query='id=217', fragment='comments' ) 


The URI parts can be depicted graphically as follows: 


http://dev.example.com:80/gallery/videos?id=217#comments 


Scheme Net Location Query Fragment 





Even though Django documentation prefers to use the term URLs, it might more technically 
correct to say that you are working with URIs most of the time. We will use the terms 
interchangeably in this book. 


Django URL patterns are mostly concerned about the 'Path' part of the URI. All other parts 
are tucked away. 


url.py 中 发 生 了 什么 ? 


It is often helpful to consider urls.py as the entry point of your project. It is usually the first file 
| open when | study a Django project. ssentially, urls.py contains the root RL 
configuration or URLConf of the entire project. 


It would be a Python list returned from patterns assigned to a global variable called 
urlpatterns. Each incoming URL is matched with each pattern from top to botto in a 
sequence. In the first atch, the search stops, and the request is sent to the corresponding 
view. 


Here, in considerably siplified for, is an excerpt of urls.py from Python.org, which was 
recently rewritten in Django: 


urlpatterns - patterns( 

# Homepage 

url(r'^$', views. IndexView.as_view(), name='home'), 

# About 

url(r'^about/$', 
TemplateView.as view(template name-"python/about.html"), 
name-'about'), 

# Blog URLs 

url(r'^blogs/', include('blogs.urls', namespace-'blog')), 

# Job archive 

url(r'Ajobs/(?P<pk>\d+)/$', 
views. JobArchive.as_view(), 
name='job_archive'), 

# Admin 

url(r'^admin/', include(admin.site.urls)), 


Some interesting things to note here are as follows: 


* The first arguent of the patterns function is the prefix. It is usually blank 

for the root URLConf. The remaining arguments are all URL patterns. 

* Each URL pattern is created using the url function, which takes five arguments. Most pa 
* The about pattern defines the view by directly instantiating TemplateView. Some hate th 
* Blog RLs are entioned elsewhere, specifically in urls.py inside the blogs app. In gener 
* The jobs pattern is the only example here of a named regular expression. 


‘| __ 








In future versions of Django, urlpatterns should be a plain list of URL pattern objects rather 
than arguments to the patterns function. This is great for sites with lots of patterns, since 
urlpatterns being a function can accept only a maximum of 255 arguments. 


If you are new to Python regular expressions, you ight find the pattern syntax to be slightly 
cryptic. Let's try to demystify it. 


URL 模 式 语法 


URL regular expression patterns can sometimes look like a confusing mass of punctuation 
marks. However, like most things in Django, it is just regular Python. 


It can be easily understood by knowing that URL patterns serve two functions: to match 
URLs appearing in a certain form, and to extract the interesting bits from a URL. 


The first part is easy. If you need to atch a path such as — /jobs/1234 , then just use the 
"Ajobs/\d+" pattern (here \d stands for a single digit from o to 9 ). Ignore the leading 
slash, as it gets eaten up. The second part is interesting because, in our example, there are 

two ways of extracting the job ID (that is, 1234 ), which is required by the view. 


The simplest way is to put a parenthesis around every group of values to be captured. Each 

of the values will be passed as a positional argument to the view. For example, the 
"Ajobs/(\d+)" pattern will send the value "1234" as the second arguent the first being 

the request to the view. 


The problem with positional arguments is that it is very easy to mix up the order. Hence, we 
have name-based arguments, where each captured value can be named. Our example will 
now look like "^jobs/(?P«pk»Nd*)/" . This means that the view will be called with a keyword 
argument pk being equal to "1234". 


If you have a class-based view, you can access your positional arguments in self. args 
and name-based arguments in self.kwargs . Many generic views expect their arguments 
solely as name-based arguments, for example, self.kwargs["slug"]. 


Mnemonic — parents question pink action-figures 


| admit that the syntax for name-based arguments is quite difficult to remember. Often, | use 
a simple mnemonic as a memory aid. The phrase "Parents Question Pink Action-figures" 
stands for the first letters of Parenthesis, Question mark, (the letter) P, and Angle brackets. 


Put them together and you get ( ?P« . You can enter the name of the pattern and figure out 
the rest yourself. 


It is a handy trick and really easy to remember. Just imagine a furious parent holding a pink- 
colored hulk action figure. 


Another tip is to use an online regular expression generator such as http://pythex. org/ or 
https://www.debuggex.com/tocraftandtestyourregularexpressions. 


命名 和 命名 空间 


Always name your patterns. It helps in decoupling your code from the exact URL paths. For 
instance, in the previous URL Conf, if you want to redirect to the about page, it might be 
tempting to use redirect("/about"). Instead, use redirect("about"), as it uses the name rather 
than the path. Here are some more examples of reverse lookups: 


>>> from django.core.urlresolvers import reverse 

>>> print(reverse("home")) 

(UA 

>>> print(reverse("job archive", kwargs={"pk":"1234"})) 
"jobs/1234/" 


Names must be unique. If two patterns have the same name, they will not work. So, some 
Django packages used to add prefixes to the pattern name. For example, an application 
named blog might have to call its edit view as 'blog-edit' since 'edit' is a common name and 
might cause conflict with another application. 


Namespaces were created to solve such problems. Pattern names used in a namespace 
have to be only unique within that namespace and not the entire project. It is recommended 
that you give every app its own namespace. For example, we can create a 'blog' namespace 
with only the blog's URLs by including this line in the root URLconf: 


url(r'^blog/', include('blog.urls', namespace-'blog')), 


Now the blog app can use pattern names, such as 'edit' or anything else as long as they are 
unique within that app. While referring to a name within a namespace, you will need to 
mention the namespace, followed by a ':' before the name. It would be "blog:edit" in our 
example. 


As Zen of Python says—"Namespaces are one honking great idea—let's do more of those." 
You can create nested namespaces if it makes your pattern names cleaner, such as 
"blog:comment:edit". | highly recommend that you use namespaces in your projects. 


T XUL 


Order your patterns to take advantage of how Django processes them, that is, top-down. A 
good rule of thumb is to keep all the special cases at the top. Broader patterns can be 
mentioned further down. The broadest—a catch-all—if present, can go at the very end. 

For example, the path to your blog posts might be any valid set of characters, but you might 
want to handle the About page separately. The right sequence of patterns should be as 
follows: 


urlpatterns - patterns( 


url(r'^about/$', AboutView.as view(), name-'about'), 
url(r'^(?P«slug»Nw-*)/$', ArticleView.as view(), name-'article'), 


If we reverse the order, then the special case, the AboutView, will never get called. 


URL 模 式 风格 


Designing URLs of a site consistently can be easily overlooked. Well-designed URLs can 
not only logically organize your site but also make it easy for users to guess paths. Poorly 
designed ones can even be a security risk: say, using a database ID (which occurs ina 
monotonic increasing sequence of integers) in a URL pattern can increase the risk of 
information theft or site ripping. 


Let's examine some common styles followed in designing URLs. 


分 布 存 储 URL 


Some sites are laid out like Departmental stores. There is a section for Food, inside which 
there would be an aisle for Fruits, within which a section with different varieties of Apples 
would be arranged together. 

In the case of URLs, this means that you will find these pages arranged hierarchically as 
follows: 


http://site.com/ <section> / <sub-section> / <item> 


The beauty of this layout is that it is so easy to climb up to the parent section. Once you 
remove the tail end after the slash, you are one level up. 


For example, you can create a similar structure for the articles section, as shown here: 


urlpatterns = patterns( 


url(r'^articles/$', include(articles.urls), namespace="articles"), 


) 
urlpatterns - patterns( 


url(r'^$', ArticlesIndex.as view(), name-'index'), 
url(r'A(?P<slug>\wt+)/$', ArticleView.as view(), name='article'), 


Notice the 'index' pattern that will show an article index in case a user climbs up from a 
particular article. 


RESTful URLs 


In 2000, Roy Fielding introduced the term Representational state transfer (REST) in his 
doctoral dissertation. Reading his thesis (http://www.ics.uci.edu/~fielding/ 
pubs/dissertation/top.htm) is highly recommended to better understand the architecture of 
the web itself. It can help you write better web applications that do not violate the core 
constraints of the architecture. 


One of the key insights is that a URI is an identifier to a resource. A resource can be 
anything, such as an article, a user, or a collection of resources, such as events. Generally 
speaking, resources are nouns. 


The web provides you with some fundamental HTTP verbs to manipulate resources: GET, 
POST, PUT, PATCH, and DELETE. Note that these are not part of the URL itself. Hence, if 
you use a verb in the URL to manipulate a resource, it is a bad practice. 


For example, the following URL is considered bad: 


http://site.com/articles/submit/ 


Instead, you should remove the verb and use the POST action to this URL: 


http://site.com/articles/ 


Best Practice 


Keep verbs out of your URLs if HTTP verbs can be used instead. 


Note that it is not wrong to use verbs in a URL. The search URL for your site can have the 
verb 'search' as follows, since it is not associated with one resource as per REST: 


http://site.com/search/?q=needle 


RESTful URLs are very useful for designing CRUD interfaces. There is almost a one-to-one 
mapping between the Create, Read, Update, and Delete database operations and the HTTP 
verbs. 


Note that the RESTful URL style is complimentary to the departmental store URL style. Most 
sites mix both the styles. They are separated for clarity and better understanding. 


下 载 练习 代码 


You can download the example code fies for all Packt books you have purchasedfrom your 
account at http://www.packtpub.com. If you purchased this bookelsewhere, you can visit 
http://www.packtpub. com/support and register tohave the fies e-mailed directly to you. Pull 
requests and bug reports to the SuperBook project can be sent to 
https://github.com/DjangoPatternsBook/superbook. 
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Views are an extremely powerful part of the MVC architecture in Django. Over time, class- 
based views have proven to be more flexible and reusable compared to traditional function- 
based views. Mixins are the best examples of this reusability. 


Django has an extremely flexible URL dispatch system. Crafting good URLs takes into 
account several aspects. Well-designed URLs are appreciated by users too. In the next 
chapter, we will take a look at Django's templating language and how best to leverage it. 
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本 章 ， 我 们 会 讨论 以 下 议题 : 


Django 模 板 语法 的 特性 
组 织 模板 

Bootstrap 

模板 继承 树 模 式 

活动 连接 模式 


WIN 


理解 Django 的 模板 语言 特点 


是 时 候 谈 谈 MTV 模 板 三 件 套 中 的 第 三 个 东西 了 。 而 你 的 团队 或 许 有 关心 模板 设计 的 设计 者 。 
或 者 你 想 要 自己 设计 模板 。 无 论 选 择 哪 种 方式 ， 你 都 需要 对 它们 非常 熟悉 。 人 毕竟 ， 模 板 是 直 
接 面向 用 户 的 。 


我 们 对 Dijango 模 板 语言 特性 进行 快速 入 门 。 
ZR X 
又 里 


每 个 模板 都 获取 一 组 上 下 文 变量 。 类 似 于 Python 的 字符 串 format() 方法 的 单 大 括 
号 {variable} 语法 ，Django 使 用 双 大 括号 {{ variable }} 语法 。 我 们 来 看 看 它们 之 间 的 比 
较 : 


。 在 纯净 的 Python 中 语法 为 ~-<h1>{title}</h1i>`。 例 如 : 
>>> "<h1>{title}</h1>".format(title="SuperBook") '<hi>SuperBook</h1>' 


。 Django 模板 中 的 相等 的 语法 是 “<h1>{f{f title }}</h1>`. 


。 如 下 传递 下 相同 的 上 下 文 产生 同样 的 结果 : 


>>> from django.template import Template, Context 

>>> Template("<hi>{{ title }}</h1>").render(Context({"title": 
"SuperBook"}) ) 

"<hi>SuperBook</h1>' 


属性 


点 号 在 Django 模 板 中 是 多 用 途 的 运算 符 。 这 里 有 三 种 不 同类 型 的 运算 符 ， 属 性 查找 ， 字 典 查 
" 列表 索引 查找 〈 依 照 顺序 ) 。 


e Python 中 我 们 首先 ， 定 义 上 下 文 变量 和 类 : 


>>> class DrOct: 
arms = 4 
def speak(self): 
return "You have a train to catch." 


>>> mydict = {"key":"value"} 
>>> mylist = [10, 20, 30] 


我 们 来 看 看 三 种 查询 类 型 的 Python 语法 : 


>>> "Dr. Oct has (0j arms and says: {1}".format(DrOct().arms, 


DrOct().speak() ) 
'Dr. Oct has 4 arms and says: You have a train to catch.' 


>>> mydict["key"] 
'value' 

>>> mylist[i] 
20 


。 Django 的 模板 等 于 下 面 : 


Dr. Oct has {{ s.arms }} arms and says: {{ s.speak }} 


{{ mydict.key }} 
{{ mylist.1 }} 


注释 


注意 Speak 方 法 没有 接受 参数 ， 除 了 被 当 作 属性 的 se/f 之 外 。 


某 些 时 候 ， det pii 。 从 根本 上 来 说 ， 你 要 利用 这 些 变量 去 调用 有 函数 。Dijango 使 用 
类 似 于 Unix 过 滤器 的 管道 语法 Hu var|methodi|method2:"tag" )) ， 而 不 
是 var.method().method2(arg) 这 样 的 链 式 函数 调用 。 


过 滤器 的 另外 一 个 限制 是 它 不 能 够 访问 模板 上 下 文 。 过 滤器 仅 在 数据 传递 到 过 滤器 ， 以 及 过 
滤器 的 参数 时 才 有 效 。 因 此 ， 在 模板 上 下 文中 它 主要 用 来 更 改变 量 。 


WS ad 


e 在 Python 中 运行 以 下 命令 


>>> title="SuperBook" 
>>> title.upper()[:5] 
'SUPER' 


e 其 对 应 的 Django 模 板 为 : 


{{ title|upper|slice:':5' }} 


标签 


编程 语言 能 够 做 的 事情 不 仅仅 是 显示 变量 。Dijango 的 模板 语言 多 中 相似 的 语法 形式 ， 比 
Je if 和 for。 它 们 应 该 用 {% if %} 这 样 的 语法 写成 。 多 个 针对 模板 的 形式 ， 上 比 
如 include 和 block 也 都 是 用 标签 语法 写成 的 。 


。 在 Python 中 运行 以 下 命令 : 


>>> if 1==1: 
print(" Date is {0} ".format(time.strftime("%d-%m-%Y"))) 
‘Date is 31-08-2014 


。 其 对 应 的 Django 模 板 形式 如 下 


{% if 1 == 1 96) Date is {% now 'd-m-Y' %} {% endif %} 


Aj 


= 





新 手 们 间 的 常见 问题 是 如 何 执行 发 现 模板 中 百分比 这 样 的 数字 计算 。 从 设计 哲学 的 角度 来 
说 ， 模 板 系统 无 意 支持 这 样 做 : 


e 对 变量 赋值 
e 高 级 逻辑 


该 决定 能 够 阻止 你 在 模板 中 添加 业务 逻辑 。 根 据 使 用 PHP 或 者 类 ASP 语 言 的 经 历 ， 将 逻辑 和 
表现 层 混 合 到 一 起 是 一 场 后 期 维护 的 焉 梦 。 不 过 ， 你 可 以 编写 自 定 义 的 模板 标签 (很 快 就 会 
学 到 ) 以 执行 任何 计算 ， 特 别 是 和 表现 层 相 关 的 计算 。 


最 佳 实践 保证 业务 逻辑 远离 模板 © 


组 织 模板 


由 startproject 命 令 创 建 的 默认 项 目 布局 并 没有 定义 好 的 模板 的 位 置 。 这 个 问题 解决 起 来 也 非 
常 简单 。 在 项 目的 根 目 录 中 创 | 建 一 个 名 称 为 templates 的 目录 。 然 后 在 settings.py 目 录 中 添 


加 rEMPLATE DIRS 变量 。 


译 者 注 在 Django 1.8 之 后 的 版 本 中 ， 已 经 不 用 手动 定义 模板 路 径 。startproject 命 令 创 建 
的 默认 配置 文件 已 经 自动 包含 了 项 目 根 目录 下 的 templates 目 录 。 


TEMPLATES = [ 
{ 

"BACKEND': 'django.template.backends.django.DjangoTemplates', 

'DIRS': [os.path.join(BASE DIR, 'templates')], 

'APP DIRS': True, 

LORTEONS SE 

'context_processors': [ 

'django.template.context processors.debug', 
'django.template.context processors.request', 
'django.contrib.auth.context processors.auth', 
'django.contrib.messages.context processors.messages', 


lo 


BASE DIR = os.path.dirname(os.path.dirname( file )) 
TEMPLATE DIRS = [os.path.join(BASE DIR, 'templates')] 


要 定义 的 就 这 么 多 。 例 如 ， 你 可 以 添加 一 个 称 做 `about .html 的 模板 ， 然 后 在 `*Urls .py ` 文 件 中 引用 它 : 


`` python 
urlpatterns = patterns('',url(r'^about/$', TemplateView.as view(template name-'about.html 


J| -— — eee 


模板 也 可 以 定义 在 应 用 中 。 在 应 用 的 目录 中 创建 模板 目录 对 存储 应 用 专用 的 模板 来 说 是 非常 
理想 的 。 





下 面 是 组 织 模板 的 一 些 优秀 实践 : 


e 再 一 个 单独 的 目录 中 ， 保 证 所 有 app 专 用 的 模板 都 放 在 这 个 app 的 模板 目录 汇总 ， 例 
如 ， projroot/app/templates/app/template ° 

e 对 模板 使 用 .html 这 样 对 扩展 名 。 

e 对 模板 添加 一 个 下 划 线 前 级 ， 表 示 将 要 继承 使 用 对 代码 片段 ， 例 如 ， navbar.html ° 
一 将 应 用 专用 的 模板 放 到 一 个 独立 的 应 用 的 模板 目录 中 ， 例 
如 ， projecroot/app/templates/app/template , 而 html 也 能 够 理解 app 两 次 出 现在 路 径 
的 原因 。 

© 为 模板 使 用 .html 格式 的 文件 扩展 名 。 

e 对 模板 使 用 带 下 划 线 的 前 级 ， 该 模板 是 能 够 在 继承 中 使 用 的 代码 片段 ， 例 


如 ， _navbar.html ° 


对 其 他 模板 语言 的 支持 


从 Django1.8 起 多 模板 引擎 将 得 到 支持 。 届 时 会 存在 内 建 的 Django 模 板 语言 (我 们 之 前 谈 到 的 
普通 模板 语言 ) 和 Jinja2 的 支持 。 在 很 多 的 性 能 基准 测试 中 ，Jinja2 比 Django 模 板 快 了 很 多 。 


对 于 指定 的 模板 引擎 和 所 有 模板 相关 的 设置 来 说 都 需要 存在 额外 的 TEMPLATES 设 置 。 而 
TEMPLATE_DIRS 设 置 很 快 也 会 被 移 除 。 


ok 


For the first time in weeks, Steve's office corner was bustling with frenetic activity. With more 
recruits, the now five-member team comprised of Brad, Evan, Jacob, Sue, and Steve. Like a 
superhero team, their abilities were deep and amazingly well-balanced. 


Brad and Evan were the coding gurus. While Evan was obsessed over details, Brad was the 
big-picture guy. Jacob's talent in finding corner cases made him perfect for testing. Sue was 
in charge of marketing and design. 


In fact, the entire design was supposed to be done by an avant-garde design agency. It took 
them a month to produce an abstract, vivid, color-splashed concept loved by the 
management. It took them another two weeks to produce an HTML-ready version from their 
Photoshop mockups. However, it was eventually discarded as it proved to be sluggish and 
awkward on mobile devices. 


Disappointed by the failure of what was now widely dubbed as the "unicorn vomit" design, 
Steve felt stuck. Hart had phoned him quite concerned about the lack of any visible progress 
to show management. In a grim tone, he reminded Steve, "We have already eaten up the 
project's buffer time. We cannot afford any last-minute surprises." 


It was then that Sue, who had been unusually quiet since she joined, mentioned that she 
had been working on a mockup using Twitter's Bootstrap. Sue was the growth hacker in the 
team—a keen coder and a creative marketer. 


She admitted having just rudimentary HTML skills. However, her mockup was surprisingly 
thorough and looked familiar to users of other contemporary social networks. Most 
importantly, it was responsive and worked perfectly on every device from tablets to mobiles. 


The management unanimously agreed on Sue's design, except for someone named 
Madame O. One Friday afternoon, she stormed into Sue's cabin and began questioning 
everything from the background color to the size of the mouse cursor. Sue tried to explain to 
her with surprising poise and calm. 


An hour later, when Steve decided to intervene, Madame O was arguing why the profile 
pictures must be in a circle rather than square. "But a site-wide change like that will never 
get over in time," he said. Madame O shifted her gaze to him and gave him a sly smile. 
Suddenly, Steve felt a wave of happiness and hope surge within him. It felt immensely 
reliving and stimulating. He heard himself happily agreeing to all she wanted. 


Later, Steve learnt that Madame Optimism was a minor mentalist who could influence prone 
minds. His team loved to bring up the latter fact on the slightest occasion. 


i | Bootstrap 


对 任何 人 来 说 开始 从 零 建设 整个 网 站 的 那些 日 子 都 是 件 很 艰苦 的 事情 。 像 推 特 的 或 者 说 是 扎 
克 伯 格 基金 会 的 Bootstrap 这 样 的 CSS 框 架 ， 栅 格 系统 ， 极 好 的 排列 板式 以 及 预先 设置 好 的 风 
格 ， 下 手 好 起 点 。 使 用 Bootstrap 的 大 多 数 网 页 设计 都 对 移动 设备 显示 友好 。 

图 片 : 略 

我 们 将 使 用 Bootstrap， 而 且 步 骤 也 类 似 于 其 他 的 CSS 框 架 。 在 网 站 中 使 用 Bootstrap 有 三 种 方 
Wei 


e Find a project skeleton: If you have not yet started your project, then finding a project 
skeleton that already has Bootstrap is a great option. A project skeleton such as edge 
(created by yours truly) can be used as the initial structure while running startproject as 
follows: 


。 寻找 项 目 架 构 : 如 果 还 没有 局 动 项目， 那么 查找 项 目 架 构 
$ django-admin.py startproject --template=https://github.com/arocks/edge/archive/master .z 
= 


可 选择 的 是 ， 你 可 以 使 用 其 中 一 个 拥有 Bootstrap 支 持 的 cookiecutter 模 板 。 





e 使 用 包 : 最 简单 的 选项 是 如 果 你 已 经 开始 对 自己 的 项 目 使 用 包 ， 比 如 django-frontend- 
skeleton 或 者 django-bootstrap-toolkit 。 


e 手动 复制 : 之 前 的 选项 并 不 能 保证 Bootstrap 的 版 本 是 最 新 的 。 而 Bootstrap 发 布 的 很 频 
繁 ， 所 以 包 的 提 着 很 难保 证 其 中 文件 的 更 新 。 因 此 ， 如 果 你 想 要 使 用 最 新 版 本 的 
Bootstrap， 最 好 的 选择 是 自己 到 这 个 地 址 下 载 http://getbootstrap.com 。 要 记得 去 阅读 发 
型 注释 ， 以 便 检 查 你 的 模版 是 否 需要 为 了 向 后 兼容 行 而 作出 改变 。 


复制 包含 css、js 的 dist 目 录 ， 以 及 静态 目录 下 根 目 录 中 的 字体 目录 。 保 证 这 个 路 径 设置 在 
settings.py 中 的 STATICFILES_DIRS : 


STATICFILES_DIRS = [os.path.join(BASE_DIR, "static")] 
Now you can include the Bootstrap assets in your templates, as follows: 
{% load staticfiles %} 
<head> 
<link href="{% static 'css/bootstrap.min.css' %}" 
rel="stylesheet"> 


怎么 它们 看 上 去 都 一 个 模样 啊 ! 


Bootstrap 或 许 是 快速 开发 的 非常 好 的 选择 。 不 过 ， 有 时 候 ， 开 发 者 懒得 去 改变 默认 的 外 观 。 
这 就 留 给 了 浏览 网 站 的 用 户 一 个 糟糕 的 映像 ， 他 们 发 现 你 的 网 站 的 外 观 也 太 熟 悉 了 而 且 很 无 
趣 o 


Bootstrap 带 来 了 很 多 的 改进 外 观 需 求 的 选项 。 如 下 ， 有 一 个 称 作 variables.less 的 文件 包 
含 了 来 自 默认 字体 的 主要 种 类 色彩 中 的 多 个 变量 : 


@brand-primary: #428bca; 

@brand-success: #5cb85c; 

@brand-info: #5bc0de; 

@brand-warning: £ZfOad4e; 

@brand-danger: #d9534f; 
@font-family-sans-serif: "Helvetica Neue", Helvetica, Arial, sans- 
serif; 

@font-family-serif: 
Qfont-family-monospace: 

monospace; 

Qfont-family-base: 

Georgia, "Times New Roman", Times, serif; 
Menlo, Monaco, Consolas, "Courier New", 
Qfont-family-sans-serif; 


Bootstrap 文 档 解 释 了 你 该 如 何 设置 构造 系统 ( 包含 LESS 编 译 器 在 内 ) ， 以 便 讲 这 些 文件 编译 
为 样式 表 。 另 外 一 个 很 方便 的 选择 是 你 去 访问 Bootstrap 往 后 在 哪 的 “定制 "区 域 以 在 线 生成 定 
制 的 样式 表 。 


要 感谢 大 量 的 有 关 Bootstrap 的 社区 ， 这 里 有 很 多 网 站 ， 比 如 bootswatch.com， 该 站 点 拥有 可 
以 替换 bootstrap.min.css 的 主题 化 样式 表 。 


另外 一 个 方法 是 重 写 Bootstrap 版 式 。 如 果 发 现 再 不 同 版 本 的 Bootstrap 之 间 升 级 自 定义 的 
Bootstrap 样 式 是 多 么 无 聊 的 事情 ， 因 为 这 只 是 个 建议 而 已 。 在 这 个 方法 中 ， 你 可 以 在 独立 的 
CSS (或 者 LESS) 文件 中 添加 自己 的 全 站 样式 ， 然 后 在 标准 的 Bootstrap 样 式 表 中 继承 它 。 这 
样 ， 你 就 能 够 以 对 全 站 样式 表 最 小 改变 来 简单 的 升级 Bootstrap 文 件 。 


最 后 然后 却 不 是 最 少 的 ， 你 可 以 让 自己 CSS 类 更 为 有 意义 以 蔡 换 结构 式 的 名 称 ， 比 如 “row” 或 
者 'column-md-4', 和 'wrapper' 或 者 'Sidebar。 如 下 ， 你 可 以 用 几 行 LESS 代 码 完 成 它 : 
-wrapper { 
.make-row(); 


.sidebar { 
.make-md-column(4); 
} 


这 是 处 理 一 个 功能 的 可 行 称 作 mixin 的 方法 ( 听 着 很 卫 熟 ， 是 吧 ! ) 。 使 用 LESS 源 码 你 可 以 完 
全 依照 自身 需求 完成 定制 。 


模板 模式 


Django 模 板 语言 非常 的 简单 。 然 而 ， 它 通过 一 些 简洁 的 模板 设计 模式 可 以 让 你 节省 很 多 的 时 
间 。 让 我 们 来 看 看 其 中 的 一 些 模板 设计 模式 。 


模式 -模板 继承 树 


问题 : 在 多 个 页 面 中 模板 存在 很 多 重复 的 内 容 。 


解决 方案 : 只 要 是 有 可 能 的 地 方 就 使 用 模板 继承 ， 并 在 其 他 地 方 继承 代码 片段 。 


问题 细节 


用 户 期 望 网 站 的 页 面 能 够 遵循 结构 的 一 致 性 。 茶 些 接口 元 素 ， 比 如 在 很 多 web 应 用 都 能 够 见 到 
的 导航 栏 菜单 ， 首 部 ， 和 页 脚 。 不 过 ， 在 每 一 个 模板 中 都 重复 它们 显示 相当 笨重 。 


大 多 数 的 模板 语言 都 拥有 模板 继承 机 制 。 其 他 文件 的 内 容 ， 也 可 以 是 一 个 模板 都 能 够 在 它们 
被 调用 的 地 方 导入 。 在 大 型 项 目 中 这 样 做 会 让 你 感到 乏味 的 。 


在 每 一 个 模板 中 将 要 继承 的 代码 片段 序列 很 大 程度 上 是 相同 的 。 倒 入 顺序 很 重要 ， 而 错误 检 
查 却 很 难 。 理 论 上 ， 我 们 能 够 创建 一 个 基础 结构 。 新 的 页 面 应 当 扩 展 这 个 基础 模板 


Django 模 板 拥有 一 个 强大 的 扩展 机 制 。 类 似 于 编程 中 的 类 ， 模 板 可 以 通过 继承 来 扩展 。 不 
过 ， 要 让 模板 工作 起 来 ，base 自 身 必要 像 下 面 这 样 组 织 到 block 中 。 


图 片 : 略 


The base.html template is, by convention, the base structure for the entire site. This 
template will usually be well-formed HTML (that is, with a preamble and matching closing 
tags) that has several placeholders marked with the {% block tags %} tag. For example, a 
minimal base.html file looks like the following: 


我 们 约定 ，base.html E Æ 4AA 3b hg JE IE yo 3X TR 


«html» 

«body» 

<hi>{% block heading %}Untitled{% endblock %}</hi> 
(96 block content %} 

(96 endblock 96) 

«/body» 

«/html» 


这 里 存在 两 个 能 够 被 重 写 块 ，heading 和 content。 你 可 以 扩展 基础 模板 以 创建 能 够 重 写 这 些 块 
的 特有 页 面 。 例 如 ， 这 里 是 一 个 about 页 面 : 


{% extends "base.html" %} 

{% block content %} 

<p> This is a simple About page </p> 
{% endblock %} 

{% block heading %}About{% endblock %} 


注意 ， 我 们 不 需要 出 现 重 复 的 结构 。 我 们 按照 任意 顺 次 饮用 block。 泻 染 结 果 将 和 定义 在 
base.html 的 内 容 一 样 在 正确 的 地 方 使 用 正确 的 block。 


如 果 继 承 的 模板 没有 重 写 block， 那 么 它 的 父 模 板 内 容 可 以 被 使 用 。 在 前 面 的 例子 中 ， 假 如 
about 模 板 不 存在 头 部 ， 那 么 它 将 拥有 默认 的 'Untitled' 头 部 。 


The inheriting template can be further inherited forming an inheritance chain. This pattern 
can be used to create a common derived base for pages with a certain layout, for example, 
single-column layout. A common base template can also be created for a section of the site, 
for example, blog pages. 


通常 ， 所 有 的 继承 链 都 可 以 通过 一 个 公共 的 根 ，base.html 来 回溯 ; 因此 ， 样 式 的 名 称 一 一 模 
板 继承 树 。 当 然 ， 这 样 的 做 法 不 需要 到 什么 技巧 的 。 而 错误 页 面 404.html 和 500.html 通 常 并 不 
需要 继承 ， 并 去 掉 了 大 多 数 的 标签 以 阻止 更 多 错误 的 发 生 。 


模式 -活动 链接 


问题 : 在 很 多 对 页 面 中 导航 栏 是 一 个 常见 对 组 件 。 然 而 ， 活 动 链 接 需 要 在 用 户 登陆 时 进行 响 
应 的 映射 。 


解决 方案 : 根据 情况 不 同 ， 通 过 设置 上 下 文 变量 或 者 请 求 路 径 来 改变 活动 链接 的 外 观 。 
问题 细节 

在 导航 栏 内 实现 活动 链接 的 简单 办 法 是 手动 地 在 每 个 一 个 需要 实现 该 功能 的 页 面 中 设置 。 不 
过 ， 这 样 过 既 不 符合 DRY 原 则 ， 也 并 不 能 保证 万 无 一 失 。 

方案 详情 

确定 活动 链接 的 解决 方法 有 多 种 。 包 括 ， 基 于 Javascript 的 方法 ， 它 们 主要 是 将 纯 模板 和 自 定 
义 标 签 组 合 到 一 起 。 

临时 模板 方案 


在 继承 导航 模板 的 代码 片段 时 可 以 饮用 一 个 称 作 active_link 的 变量 ， 这 个 方案 实现 起 来 既 简 单 
又 容易 。 


在 每 一 个 模板 中 ， 你 都 需要 包括 以 下 内 容 (或 者 继承 它 ) 


{% include " navbar.html" with active link-'link2' %} 


_navbar ,html 文件 包含 了 拥有 一 组 检查 活动 链接 的 变量 的 导航 菜 


{# _navbar.html #} 
<ul class="nav nav-pills"> 


<li{% if active link == "linki" %} class="active"{% endif %}><a 
href="{% url 'link1' %}">Link 1</a></li> 

«li(? if active link == "link2" %} class="active"{% endif %}><a 
href="{% url 'link2' %}">Link 2«/a»«/li» 

«li(? if active link == "link3" %} class="active"{% endif %}><a 
href="{% url 'link3' %}">Link 3«/a»«/li» 
«/ul» 


自 定义 标签 


Django 模 板 提 供 了 一 组 多 功能 的 内 好 标签 。 创 建 自己 自 定义 标签 很 简单 。 因 此 自 定义 标签 是 
使 用 在 应 用 内 部 的 ， 那 么 n 用 的 内 部 创建 一 个 称 作 templatetags 到 目录 。 这 个 目录 必 
须 是 一 个 Python 包 ， 所 以 应 该 包 ^ (CE) init .py 文件 。 


接 下 来 ， 在 给 定名 称 的 Python 文件 中 编写 自己 的 自 定义 模板 。 例 如 ， 对 于 激活 链接 样式 ， 我 
们 可 以 使 用 一 下 内 容 创 建 一 个 称 作 nav.py 的 文件 : 


+ app/templatetags/nav.py 
from django.core.urlresolvers import resolve 
from django.template import Library 


register = Library() 
@register.simple_tag 


def active_nav(request, url): 
url name = resolve(request.path).url name 


if url name -- url: 
return "active" 
return "" 


这 个 文件 定义 了 一 个 称 作 active nav 的 自 定义 标签 。 它 从 request 参 数 重新 取 回 URL 的 路 径 组 
TF ( 即 ， 第 四 章 一 一 视图 与 路 由 ， 其 中 有 对 URL 路 径 对 详细 说 明 ) 。 然 后 resolve() 函 数 用 来 从 
径 查 询 URL 的 样式 名 称 (定义 在 urls.py 中 ) 。 最 后 ， 让 仅 在 样式 名 称 匹 配 期 望 的 样式 名 称 

时 反悔 字符 囊 “active”。 
在 模板 中 调用 这 个 自 定义 标签 的 语法 是 {% active_nav request 'pattern_name' %} ° 注意 , dE 


用 到 这 个 标签 的 每 个 地 方 都 需要 将 request 传 递 进去 。 


在 多 个 视图 中 使 用 一 个 变量 显得 太 策 抽 了 。 如 下 ， 我 们 在 settings.py 中 添加 一 个 内 建 的 上 下 文 
处 理 器 到 TEMPLATE CONTEXT. PROCESSORS ,redquest 便 可 以 用 request 变 量 的 身份 出 现在 整个 网 站 
f: 


# settings.py 
from django.conf import global_settings 


TEMPLATE_CONTEXT_PROCESSORS = \ 
global_settings.TEMPLATE_CONTEXT_PROCESSORS + ( 
'django.core.context processors.request', 


现在 ， 在 模板 中 剩 下 的 内 容 要 使 用 这 个 定制 标签 ， 这 样 就 可 以 设置 激活 属性 了 


{# base.html #} 
{% load nav %} 
<ul class="nav nav-pills"> 

«li class={% active nav request 'activei1' %}><a href="{% url 
'active1' %}">Active 1</a></1li> 

«li class={% active nav request 'active2' %}><a href="{% url 
'active2' %}">Active 2«/a»«/li» 

«li class={% active nav request 'active3' %}><a href="{% url 
'active3' %}">Active 3«/a»«/li» 
«/ul» 


Bo 
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在 这 一 章 ， 我 们 浏览 了 Django 的 模板 特性 。 因 为 在 Django 中 切换 模板 语言 很 简单 ， 所 以 很 多 
人 都 考虑 替换 。 不 过 ， 在 浏览 其 他 的 选择 之 前 重要 的 是 学 些 内 建 模板 语言 的 设计 哲学 。 


下 一 章 ， 我 们 会 学 习 Django 的 杀手 级 功能 ， 即 ，admin 接 口 ， 以 及 我 们 如 何 定制 它 


第 六 章 -Admin 接 口 


这 一 章 ， 我 们 会 讨论 以 下 话题 : 


e 定制 admin 

e 增强 admin 的 模型 

。 Admin 的 最 佳 实践 

e 特性 标识 
Django 被 谈论 到 最 多 的 是 , 与 其 他 的 竞争 对 手相 比 它 将 admin 接 口 独立 了 出 来 。。admin 接 口 
是 一 个 自动 地 生成 添加 和 修改 一 个 站 点 内 容 的 用 户 接 口 。 不 仅 如 此 ，admin 也 是 Django 的 杀手 
级 应 用 ， 它 使 项 目 中 对 模型 生成 admin 接 口 的 乏味 的 任务 可 以 自动 化 。 


admin 能 够 让 你 的 团队 在 同一 时 间 内 添加 内 容 ， 不 间断 开发 。 只 要 模型 已 经 应 用 了 迁移 ， 你 仅 
需 添 加 一 行 或 者 两 行 代码 就 可 以 生成 模型 的 的 admin 接 口 。 


使 用 admin 接 口 


在 Django1.7 中 ，admin 接 口 默 认 是 启用 的 。 在 创建 项 目 之 后 ， 你 浏 
览 http://127.0.0.1:800/admin 时 能 够 看 到 一 个 登录 页 面 。 
如 果 输 入 超级 用 户 凭证 (或 者 任意 站 点 注册 用 户 的 凭证 ) ， 那 么 你 会 登录 到 admin 中 ， 一 如 下 
面 截 图 所 示 : 
不 过 ， 模型 在 admin 管 理 界 面 是 不 可 见 的 除非 你 定义 一 个 与 之 对 应 的 ModelAdmin 类 。 这 个 
操作 通常 定义 在 应 用 的 admin.py 文 件 ， 一 如 下 面 所 示 : 

from django.contrib import admin 


from . import models 
admin.site.register(models.SuperHero) 


此 处 ， Modeladmin 的 到 注册 器 的 第 二 个 参数 被 省 略 。 因 此 ， 我 们 会 获得 一 个 默认 的 Post 模 型 
的 admin 接 口 。 让 我 们 看 看 如 何 创建 并 自 定义 `ModelAdmin 类 。 


Django 设计 模式 与 最 佳 实践 


注释 


5] X& A, “AA vni es? "一 个 声音 来 自 备 餐 室 角 落 的 声音 问 道 。 苏 差点 儿 把 咖啡 酒 了 出 
来 。 她 前 面 站 着 一 位 身 着 紧身 红 蓝 相间 衣服 ， 面 带 微笑 ， 将 手 又 在 腰 间 的 高 个 子 男 人 。 


"Oh, my god," said Sue as she wiped the coffee stain with a napkin. "Sorry, | think | 
scared you," said Captain Obvious "What is the emergency?" "Isn't it obvious that she 
doesn't know?" said a calm feminine voice from above. Sue looked up to find a 
shadowy figure slowly descend from the open hall. Her face was partially obscured by 
her dark matted hair that had a few grey streaks. "Hi Hexa!" said the Captain "But then, 
what was the message on SuperBook about?" 


“哎哟 喂 ，" 苏 说 道 ， 同 时 另 一 边 她 小 毛巾 探 掉 了 小 出 去 的 咖啡 。“ 不 好 意 啊 ， 吓 到 你 
了 ，” 装 傻 队长 问 道 。“ 什 么 事 这 么 急 啊 ?了 ” 


Soon, they were all at Steve's office staring at his screen. "See, | told you there is no 
beacon on the front page," said Evan. "We are still developing that feature." "Wait," said 
Steve. "Let me login through a non-staff account." In a few seconds, the page refreshed 
and an animated red beacon prominently appeared at the top. "That's the beacon | was 
talking about!" exclaimed Captain Obvious. "Hang on a minute," said Steve. He pulled 
up the source files for the new features deployed earlier that day. A glance at the 
beacon feature branch code made it clear what went wrong: 


几 秒 钟 之 后 ， 页 面 重 新 剧 新 ， 然 后 一 个 重要 的 红色 提醒 出 现在 顶部 。“ 这 就 是 我 提 到 的 信 
标 1 " 装 傻 队长 说 道 。" 稍 等 一 下 啊 ，" 斯 蒂 夫 说 到 。 他 从 前 些 天 部 署 的 新 功能 拉 取 了 原文 
件 。 稍 微 看 下 信 标 功能 的 分 支 代 码 能 够 搞 清 楚 到 底 哪里 出 问题 了 : 


if switch is active(request, 'beacon') and not 
request.user.is staff(): 
# Display the beacon 


EE 
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Django 设计 模式 与 最 佳 实践 


“各 位 不 好 意思 ，? 斯 荫 夫 说 道 。“ 这 里 出 现 了 一 个 逻辑 错误 。 我 们 一 时 下 忽 就 将 该 功能 的 
启用 开放 给 了 所 有 人 ， 而 不 是 仅 有 站 点 注册 用 户 来 开启。 现在 我 把 这 个 功能 给 关闭 了 。 
对 于 因此 而 引起 的 混乱 我 表示 妥 意 。” 


"So, there was no emergency?" said Captain with a disappointed look. Hexa put an arm 
on his shoulder and said "| am afraid not, Captain." Suddenly, there was a loud crash 
and everyone ran to the hallway. A man had apparently landed in the office through one 
of the floor-to-ceiling glass walls. Shaking off shards of broken glass, he stood up. 
"Sorry, | came as fast as | could," he said, "Am | late to the party?" Hexa laughed. "No, 
Blitz. Been waiting for you to join," she said. 


这 么 说 ， 根 本 没什么 要 紧 事 唆 ? ?队长 带 着 一 脸 失 望 回 的 说 道 。Hexa 一 面 把 手 搭 在 他 月 
膀 上 一 边 说 道 : “我 也 不 希望 发 生 什 么 事情 ， 队 长 。” 突 然 之 间 ， 室 内 闪现 出 一 团 云 ， 屋 里 
的 人 都 赶紧 跑 开 了 。 


增强 用 于 admin 的 模型 


admin 应 用 足够 聪明 ， 因 此 它 可 以 自动 地 从 模型 发 现 非 常 多 东西 。 可 是 ， 有 时 候 推定 信息 需要 
改进 。 这 通常 涉及 到 模型 自身 添加 一 个 属性 或 者 一 个 方法 〈 而 不 是 在 ModelAdmin 类 中 添 
fia) œ 


首先 ， 为 了 更 好 的 说 明 问 题 ， 让 我 们 来 看 一 个 包括 admin 接 口 而 增强 模型 的 例子 : 


# models.py 
class SuperHero(models.Model): 
name = models.CharField(max_length=100) 
added on - models.DateTimeField(auto now add-True) 


def — str (self): 
return "(0j - {1:%Y-%m-%d 96H:96M:96S)" . format (self .name, 
self.added on) 
def get absolute url(self): 
return reverse('superhero.views.details', args-[self.id]) 
class Meta: 
ordering - ["-added on"] 


verbose name - "superhero" 
verbose name plural - "superheroes" 


我 们 看 看 admin 是 如 何 利 用 这 些 非 字段 属性 的 : 


。_ str (): 没有 它 的 话 ，Superhero 条 目的 列表 看 上 去 会 极其 无 趣 的 。 每 一 个 条 目 都 请 清楚 地 显示 为 “<Supe 
e get absolute url(): 如 果 你 喜欢 在 网 站 中 的 admin 视 图 和 对 象 详细 视图 之 间 切 换 ， 该 属性 会 很 方便 的 。 如 果 
。 ordering: 如 果 没 有 这 个 元 选项 ， 你 的 条 目 会 在 数据 数据 库 返 回 后 以 任意 顺序 出 现 。 你 也 可 以 想象 一 下 ， 如 果 俐 
e verbose name: 如 果 你 忽略 该 属性 ， 模 型 的 名 称 会 从 `CamelCase ` 转 换 到 `camelcase`。 这 个 例子 中 ，“sur 
e verbose name plural: 再 者 ， 忽 略 该 选项 能 够 给 你 带 来 比较 有 趣 的 结果 。 因 为 Django 简 单 地 将 一 个 ‘Ss' 预 办 
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里 建议 你 定义 前 面 的 Meta 属性 和 方法 ， 而 不 仅仅 是 只 用 于 admin 接 口 ， 而 且 也 是 为 了 在 
shell 中 和 日 志文 件 中 ， 等 等 中 更 好 的 表现 内 容 。 


当然 ， 你 也 可 以 像 下 面 这 样 ， 通 过 创建 一 个 ModelAdmin 类 来 进 进 在 admin 里 的 显示 : 
+ admin.py 
class SuperHeroAdmin(admin.ModelAdmin): 


list display = ('name', 'added on') 

search fields - ["name"] 

ordering - ["name"] 
admin.site.register(models.SuperHero, SuperHeroAdmin) 


我 们 来 看 看 这 些 更 为 严密 的 选 


e list-display: 该 选项 在 一 个 表格 形式 的 表单 中 该 显示 模型 实例 。 它 显示 每 个 独立 可 排序 列 
的 字段 。 如 果 你 希望 看 到 模型 的 多 个 属性 ， 该 3 ee 

e search fields: 该 选项 在 列表 上 面 显示 一 个 搜索 框 。 任 何 的 输入 的 搜索 项 都 可 以 搜索 到 对 
应 的 引用 字段 。 因 此 ， 仅 有 CharField 或 者 TextField 这 样 的 文本 字段 被 引用 。 


。 ordering: 该 选项 优先 于 模型 的 默认 顺序 。 在 admin 后 台 管理 中 选择 一 个 不 同 的 顺序 时 ， 
会 很 有 用 的 。 


图 片 : 略 
前 面 的 截图 插入 内 容 为 : 


e. 插入 内 容 1: 不 使 用 str 或 者 Meta 属 性 
e 插入 内 容 2: 使 用 增强 的 模型 meta 属 性 
e 插入 内 容 3: 使 用 定制 的 ModelAdmin 


这 里 我 们 仅仅 提 到 了 一 个 常用 的 amdin 选 项 子 集 。 茶 些 类 型 的 网 站 会 重度 地 使 用 admin 接 口 。 
在 这 样 地 情况 下 ， 这 里 强烈 建议 你 彻 彻底 底 搞 明 白 Django 文 档 的 admin 部 分 


不 应 该 让 所 有 人 都 成 为 admin 


Since admin interfaces are so easy to create, people tend to misuse them. Some give early 
users admin access by merely turning on their 'staff' flag. Soon such users begin making 
feature requests, mistaking the admin interface to be the actual application interface. 


因为 admin 接 口 很 轻松 就 可 以 创建 了 ， 所 以 有 可 能 被 滥 


Unfortunately, this is not what the admin interface is for. As the flag suggests, it is an internal 
tool for the staff to enter content. It is production-ready but not really intended for the end 
users of your website. It is best to use admin for simple data entry. For example, in a project 


| had reviewed, every teacher was made an admin for a Django application managing 
university courses. This was a poor decision since the admin interface confused the 
teachers. 


不 幸 的 是 这 不 是 admin 接 口 的 本 来 目的 。 


The workflow for scheduling a class involves checking the schedules of other teachers and 
students. Using the admin interface gives them a direct view of the database. There is very 
little control over how the data gets modified by the admin. 


So, keep the set of people with admin access as small as possible. Make changes via admin 
sparingly, unless it is simple data entry such as adding an article's content. 


因此 ， 你 要 保持 能 够 访问 admin 人 群 数量 尽 可 能 少 。 通 过 admin 操 作 地 变更 要 谨 惯 ， 除 非 是 添 
加 一 篇 文章 内 容 这 样 地 简单 数据 条 目 操 作 。 
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Ensure that all your admins understand the data inconsistencies that can arise from making 
changes through the admin. If possible, record manually or use apps, such as django-audit- 
loglog that can keep a log of admin changes made for future reference. 


确保 


In the case of the university example, we created a separate interface for teachers, such as 
a course builder. These tools will be visible and accessible only if the user has a teacher 
profile. 


Essentially, rectifying most misuses of the admin interface involves creating more powerful 
tools for certain sets of users. However, don't take the easy (and wrong) path of granting 
them admin access. 


admin 接 口 的 定制 
开 箱 即 用 单 admin 接 口 对 于 准备 使 用 它 的 人 来 说 非常 有 用 。 不 幸 的 是 ， 很 多 人 都 假设 改变 


Django 的 admin 肯 定 非常 困难 ， 然 后 就 撒手 不 管 了 。 实 际 上 ，admin 是 属于 极其 易于 定制 的 ， 
它 的 外 观 可 以 用 最 小 的 努力 就 得 以 改变 。 


改变 标题 


Many users of the admin interface might be stumped by the heading—Django 
administration. It might be more helpful to change this to something customized such as 
MySite admin or something cool such as SuperBook Secret Area. 


很 多 admin 用 户 或 许 被 标题 一 Django administration 给 难 住 了 。 





要 改变 标题 是 很 容易 的 。 在 站 点 的 urls.py 中 添加 下 面 这 行内 容 就 好 了 : 


admin.site.site_header = "SuperBook Secret Area" 


改变 基本 样式 


几乎 所 有 的 admin 页 面 都 扩展 自 叫 做 admin/base _site.html 都 公共 基本 模板 。 这 意味 着 只 需 用 
到 少量 都 HTML 和 CSS 的 知识 ， 因 此 你 可 以 定制 所 有 的 排序 以 改变 admin 接 口 的 外 观 和 视觉 。 


先 简单 地 在 任意 地 模板 目录 中 创建 一 个 名 称 为 admin 的 目录 。 然 后 ， 从 Django 源 目录 复制 文件 
base_site.html， 并 按照 自己 的 需要 做 相应 的 变更 。 如 果 你 不 知道 模板 的 位 置 ， 那 么 在 Django 
shell 中 运行 下 面 的 命令 就 是 了 : 


>>> from os.path import join 
>>> from django.contrib import admin 
>>> print(join(admin. path [0], "templates", "admin")) 


例如 ， 定 制 admin 的 基础 模板 ， 你 可 以 改变 admin 接 口 的 整个 字体 为 谷歌 字体 “Special Elite" > 
谷歌 的 这 个 字体 看 上 去 非常 的 厚重 。 你 需要 使 用 以 下 内 容 在 项 目 中 的 模板 目录 中 添加 一 个 文 
fFadmin/base site.html ; 


{% extends "admin/base.html" 96) 
(96 block extrastyle %} 

«link href='http://fonts.googleapis.com/css?family=Special+Elite' 
rel-'stylesheet' type='text/css'> 

«style type="text/css"> 

body, td, th, input { 
font-family: 'Special Elite', cursive; 

) </style> 
(96 endblock 96) 


该 代码 通过 添加 一 个 附加 的 样式 表 来 重 写 与 字体 相关 的 样式 ， 而 且 附 加 的 样式 会 应 用 于 每 个 
admin 的 页 面 。 


添加 富 文 本 编辑 器 


有 时 候 ， 你 需要 在 admin 接 口中 使 用 JavaScript 代 码 。 常 见 的 一 个 需求 就 是 对 TextField 使 用 
CKEditor 这 样 的 HTML 编 辑 器 。 


在 Django 中 有 多 种 实现 这 个 编辑 器 的 方法 ， 例 如 ， 对 ModleAdmin 类 使 用 一 个 Media 内 部 类 。 
不 过 ， 我 发 现 扩 展 admin 的 change form 模 板 是 最 方便 的 方法 。 


例如 ， 假 如 你 拥有 一 个 称 作 Posts 的 应 用 ， 那 么 你 需要 去 在 template/admin/posts/directory 目 
录 之 内 新 建 一 个 称 作 change form.html 的 文件 。 如 果 你 需要 在 这 个 应 用 内 的 任意 模型 中 显示 
CKEditor， 那 么 这 个 文件 的 内 容 是 这 个 样子 的 : 


/home/arun/env/sbenv/lib/python3.4/site-packages/django/contrib/admin/templates/admin 


该 文件 中 的 最 后 一 行 是 所 有 admin 模 板 中 的 位 置 所 在 。 你 可 以 重 写 或 者 扩展 这 些 模板 中 的 任何 
一 个 。 可 以 参考 下 一 小 节 的 扩展 模板 的 例子 。 


{% extends "admin/change form.html" %} 
{% block footer %} 
{{ block.super }} 
«script src="//cdn.ckeditor.com/4.4.4/standard/ckeditor.js"></ 
script> 
«script» CKEDITOR.replace("id message", ( 
toolbar: [ 
[ 'Bold', 'Italic', '-', 'NumberedList', 'BulletedList'],], 
width: 600, 
1); 


</script> 

<style type="text/css"> 
.Cke { clear: both; } 

</style> 

{% endblock %} 


高 亮 的 部 分 是 用 于 我 们 希望 将 一 个 普通 的 文本 输入 框 加 强 为 富 文本 编辑 器 的 表单 元 素 的 自动 
创建 的 ID。 这 些 脚 本 和 样式 眼睛 被 添加 到 了 footer 块 ， 这 样 表单 元 素 可 以 在 自身 被 改变 之 前 ， 
于 DOM 中 创建 。 


使 用 Bootstrap 主 题 的 admin 


总 的 来 说 ，admin 接 口 已 经 设计 非常 好 了 。 不 过 ， 由 于 它 是 在 2006 年 设计 的 ， 而 且 是 为 了 显 
示 效 果 的 通用 性 做 出 的 设计 。 因 此 ， 它 没有 适应 mobile 设 备 ， 或 者 是 拥有 其 他 的 已 经 成 为 今 
日 事实 标准 的 细节 部 分 。 

毫 不 奇怪 的 是 admin 定 制 中 最 常见 要 求 是 确定 是 否 可 以 继承 Bootstrap。 有 多 个 包 可 以 实现 这 
个 需求 ， 比 如 django-admin-bootstrapped 或 者 djangosuit 。 


这 些 包 提供 了 开 箱 即 用 的 基于 Bootstrap 主 题 的 模板 ， 而 不 是 你 自己 去 重新 编写 所 有 的 admin 
模板 。 因 为 基于 Bootstrap， 所 以 它们 拥有 响应 式 功能 ， 而 且 包 含 了 多 种 部 件 和 组 件 。 


admin 接 口 也 已 经 在 我 们 的 尝试 下 完全 的 重 写 了 。Grappelli 是 一 个 非常 流行 皮肤 ， 它 能 够 利用 
功能 扩展 Django admin， 比 如 自动 查询 和 折 咎 吝 套 。 使 用 django-admin-tools， 你 可 以 获得 一 
个 可 定制 的 面板 和 工具 栏 。 


There have been attempts made to completely rewrite the admin, such as django-admin2 
and nexus, which did not gain any significant adoption. There is even an official proposal 
called AdminNext to revamp the entire admin app. Considering the size, complexity, and 
popularity of the existing admin, any such effort is expected to take a significant amount of 
time. 


这 里 也 有 完全 重 写 admin 的 尝试 ， 比 如 django-admin2 和 nexus， 它 们 不 会 着 重 使 用 的 。 


保护 admin 


The admin interface of your site gives access to almost every piece of data stored. So, don't 
leave the metaphorical gate lightly guarded. In fact, one of the only telltale signs that 
someone runs Django is that, when you navigate to http://example. com/admin/, you will be 
greeted by the blue login screen. 


网 站 的 admin 接 口 几乎 访问 了 每 一 块 存储 的 数据 。 因 此 ， 不 要 留 下 缺少 保护 的 后 门 。 实 际 上 ， 
在 生产 环境 中 ， 我 们 建议 你 将 这 个 地 址 改 为 不 太 显 眼 的 地 址 。 在 项 目的 根 urls.py 中 尽 可 能 简 


单 地 变更 该 行 : 


url(r'^secretarea/', include(admin.site.urls)), 


— 4S FH i 38. po i) BK eH RUE BE VBR admins: ARASH (参见 第 三 方 

包 django-admin-honeypot ) 。 不 过 ， 最 好 的 选择 对 admin 站 点 范围 内 使 用 HTTPS， 因 为 常规 
的 HTTP 会 把 所 有 的 数据 以 明文 格式 发 送 到 网 络 中 去 。 

检查 Web 服务器 的 文档 ， 看 看 如 何 为 到 admin 的 请 求 设 置 HTTPS。 在 NginXx 上 面 ， 设 置 这 个 连 
接 方式 非常 的 简单 ， 涉 及 到 的 有 指定 SSL 认 证 位 置 。 最 后 ， 将 所 有 到 admin 页 面 的 HTTP 请 求 
重 定 向 到 HTTPS， 现 在 可 以 安生 地 睡 个 好 觉 了 。 


The following pattern is not strictly limited to the admin interface but it is nonetheless 
included in this chapter, as it is often controlled in the admin. 


模式 一 功能 标识 


遇 到 的 问题 : 对 用 户 发 布 的 新 功能 ， 以 及 在 生产 环境 中 部 署 的 对 应 代码 都 应 当 是 互相 独立 
的 。 


解决 方法 : 在 部 署 之 后 ， 使 用 功能 标识 有 选择 性 地 启动 或 者 禁用 功能 。 


问题 细节 


Rolling out frequent bug fixes and new features to production is common today. Many of 
these changes are unnoticed by users. However, new features that have significant impact 
in terms of usability or performance ought to be rolled out in a phased manner. In other 
words, deployment should be decoupled from a release. 


现 如今 ， 惯 常 的 bug 修 复 和 新 功能 在 生产 环境 中 是 很 常见 的 。 对 于 用 户 这 些 改变 中 很 多 的 改变 
是 不 被 通知 的 ° Rit , 


Simplistic release processes activate new features as soon as they are deployed. This can 
potentially have catastrophic results ranging from user issues (swamping your support 
resources) to performance issues (causing downtime). 


TH Ru 


Hence, in large sites it is important to decouple deployment of new features in production 
and activate them. Even if they are activated, they are sometimes seen only by a select 
group of users. This select group can be staff or a sample set of customers for trial 
purposes. 


因此 ， 在 生产 环境 中 对 于 大 型 站 点 来 说 最 重要 的 是 解构 新 功能 的 部 署 ， 并 激活 这 些 新 功能 。 
即使 这 些 新 功能 被 激活 了 ， 它 们 也 只 是 仅仅 对 被 选择 了 的 用 户 可 见 。 这 个 被 挑选 出 来 的 组 可 
以 是 站 点 注册 成 员 ， 也 可 以 是 一 组 简单 的 出 于 试验 目的 而 存在 的 用 户 。 


解决 方法 细节 


Many sites control the activation of new features using Feature Flags. A feature flag is a 
switch in your code that determines whether a feature should be made available to certain 
customers. 


很 多 网 站 的 新 功能 激活 是 透 过 功能 标识 实现 的 。 功 能 标识 是 一 个 代码 中 的 可 以 决定 一 个 功能 
是 否 对 某 些 用 户 开放 的 开关 。 


Django 有 多 个 提供 功能 标识 的 包 ， 比 如 gargoyle 和 django-waffle。 这 些 包 在 网 站 的 数据 库 中 
存储 功能 标识 。 他 们 能 够 透 过 admin 接 口 或 者 管理 命令 进行 激活 或 者 失效 。 因 此 ， 每 一 种 环境 
(生产 、 测 试 、 开 发 、 等 等 ) 都 可 以 拥有 属于 自己 的 一 组 激活 功能 。 


Feature flags were originally documented, as used in Flickr (See http://code. 
flickr.net/2009/12/02/flipping-out/). They managed a code repository without any branches, 
that is, everything was checked into the mainline. They also deployed this code into 
production several times a day. If they found out that a new feature broke anything in 
production or increased load on the database, then they simply disabled it by turning that 
feature flag off. 


功能 旗帜 是 得 到 原生 的 文档 支持 ， 一 如 用 在 Flickr。 它 们 不 用 任何 分 支管 理 代码 仓库 ， 即 ， 一 
切 内 容 都 记录 到 主线 中 。 它 们 在 一 天 可 以 多 次 部 署 到 dic NE 产 环境 中 发 现 新 
的 功能 破坏 了 任何 其 他 东西 ， 或 者 增加 了 数据 库 的 负载 ， 那 么 它们 都 通过 关闭 功能 旗帜 来 简 
单 的 禁用 。 


Feature flags can be used for various other situations (the following examples use django- 
waffle): 


功能 标识 可 以 用 于 多 种 情况 〈 下 面 的 例子 使 用 的 是 django-waffle ) 


e Trials: A feature flag can also be conditionally active for certain users. These can be 
your own staff or certain early adopters than you may be targeting as follows: 

e 试用 : 功能 标识 也 可 以 根据 条 件 针对 部 分 用 户 激活 。 
如 下 ， 这 些 用 户 可 以 是 站 点 的 注册 成 员 ， 或 者 某 些 你 想 指 定 监护 人 : 


def my_view(request): 
if flag_is au m pape ene 


Behavi 


or if flag 


Sites can run several such trials in parallel, so different sets of users might actually have 
different user experiences. Metrics and feedback are collected from such controlled tests 
before wider deployment. 


站 点 可 以 平行 的 运行 多 个 试用 ， 这 样 不 同 组 的 用 户 实际 上 可 以 拥有 不 同 的 用 户 体验 。 在 大 范 
围 部 署 之 前 ， 可 以 从 这 里 可 控制 的 测试 中 收集 质量 和 反馈 。 


e A/B testing: This is quite similar to trials except that users are selected randomly within 
a controlled experiment. This is quite common in web design to identify which changes 
can increase the conversion rates. This is how such a view can be written: 

© ABR IK : 该 测试 很 类 似 于 体验 测试 ， 除 了 用 户 在 被 控制 的 试验 中 随机 地 选择 用 户 。 对 于 
web 设 计 来 说 识别 出 哪个 变更 能 够 增加 转换 速率 是 相当 常见 的 。 这 也 展示 这 样 的 一 个 视图 
是 如 何 编写 的 : 


def my_view(request): 
if sample_is_active(request, 'design name'): 


/ior Tor test sampie. 3 


e Performance testing: Sometimes, it is hard to measure the impact of a feature on server 
performance. In such cases, it is best to activate the flag only for a small percentage of 
users first. The percentage of activations can be gradually increased if the performance 
is within the expected limits. 

e 性 能 测试 : 有 时 候 ， 很 难 去 测量 服务 器 上 一 个 功能 性 能 影响 。 这 类 例子 中 ， 最 好 是 首先 
仅 对 一 小 部 分 激活 旗帜 。 如 果 性 外 | > 激活 百分比 可 以 逐渐 地 增加 。 


e Limit externalities: We can also use feature flags as a site-wide feature switch that 
reflects the availability of its services. For example, downtime in external services such 
as Amazon S3 can result in users facing error messages while they perform actions, 
such as uploading photos. 


e 扩展 性 的 限制 : RAT VALE A JI ARE 


When the external service is down for extended periods, a feature flag can be deactivated 
that would disable the upload button and/or show a more helpful message about the 
downtime. This simple feature saves the user's time and provides a better user experience: 


当 扩 展 服务 因为 扩展 周期 而 关闭 时 ， 新 的 功能 旗帜 被 取消 激活 将 会 禁用 上 传 按钮 同时 或 者 
显示 关于 关闭 时 间 更 为 有 帮助 的 消息 。 这 个 简单 的 功能 保存 了 用 户 的 时 间 并 提供 了 更 好 的 用 
PRE: 

def my (request): 


afi switch | is d SS SOWIE ) : 


isable uploads and show it is downtime 4/1] Et## 


The main disadvantage of this approach is that the code gets littered with conditional 
checks. However, this can be controlled by periodic code cleanups that remove checks for 
fully accepted features and prune out permanently deactivated features. 


这 个 方法 的 主要 缺点 是 按照 某 些 条 件 检 查 代 码 会 变 得 垃圾 。 不 过 ， 


本 章 我 们 探 完了 Django 的 内 建 应 用 admin。 我 们 发 现 了 它 不 仅仅 是 非常 好 用 的 开 箱 即 用 ， 而 且 
可 以 实现 各 种 定制 ， 以 改进 它 的 外 观 和 功能 。 


下 一 章 ， 我 们 将 会 通过 思考 多 种 模式 和 常见 用 法 来 学 习 在 Django 中 如 何 更 有 效 的 使 用 表单 。 


这 一 章 我 们 会 讨论 一 下 话题 : 


。 表单 的 工作 流程 
。 不 可 靠 的 输入 
。 表单 处 理 类 视图 
。 表单 与 CRUD 视 图 


我 们 把 Django 表 单 放 到 一 边 ， 来 讨论 下 常规 情况 下 的 表单 是 个 什么 样子 。 表 单 不 仅 长 ， 而 且 
有 着 多 个 需要 填充 的 无 趣 的 页 面 。 可 以 说 表单 无 所 不 在 。 我 们 每 天 都 用 到 它 。 表 单 支 撑 了 谷 
歌 搜 索 框 到 脸 书 的 点 赞 按钮 这 所 有 的 一 切 。 


Django 把 使 用 表单 时 产生 的 验证 和 描述 这 类 的 大 量 繁重 工作 给 抽象 了 。 它 也 实现 了 多 种 的 安 
全 问题 的 最 佳 实践 。 可 是 ， 表 单 在 处 理 自身 多 个 状态 之 一 时 也 是 令 人 困惑 的 起 因 。 


表单 的 工作 原理 


表单 理解 起 来 比较 困难 ， 因 为 它 同 不 止 一 个 请 求 -响应 循环 交互 。 最 简单 的 场景 是 ， 你 需要 展 
示 一 个 空 表单 ， 然 后 用 户 来 正确 地 填充 和 提交 表单 。 另 外 一 种 情况 是 它们 输入 一 些 无 效 的 数 
据 ， 表 单 需 要 重复 的 提交 知道 整个 表单 有 效 为 止 。 


因此 ， 表 单 表 现 出 多 种 状态 : 


。 ERE: 在 Django 中 此 表单 称 为 未 绑 定 表单 

。 已 填充 表单 : Django 中 该 表单 称 为 已 绑 定 表单 

© 有 错误 的 已 提交 表单 : 该 表单 称 做 已 绑 定 表单 ， 但 不 是 有 效 表 单 
e 没有 错误 的 已 提交 表单 : 该 表单 称 做 已 绑 定 且 有 效 的 表单 


注意 用 户 永 远 不 会 见 到 表单 的 最 后 状态 。 他 们 不 必 如 此 。 提 交 的 有 效 表单 应 当 把 用 户 带 到 表 
单 提 交 成 功 之 后 的 页 面 。 


Django ? 5 & X- 
通过 总 结 它们 到 一 个 层次 ，Django 的 form 类 每 个 字段 的 状态 ， 以 及 表单 自身 。 表 单 拥有 两 个 
重要 的 状态 属性 ， 一 如 下 面 所 示 : 


。 is bound: 如 果 返 回 值 为 假 ， 则 它 是 一 个 未 绑 定 的 表单 ， 即 ， 新 的 空 表单 ， 或 者 默认 的 字 
段 值 。 如 果 返 回 值 为 版 ， 表 单 被 绑 定 ， 即 ， 至 少 有 一 个 用 户 设置 的 字段 。 


e is valid(): 如 果 返 回 值 为 真 ， 已 绑 定 表单 中 的 所 有 字段 都 拥有 有 效 的 数据 。 如 果 返 回 假 ， 
至 少 有 一 个 字段 中 存在 一 部 分 无 效 数据 ， 或 者 表单 未 被 绑 定 。 


举例 来 说 ， 想 象 一 下 你 需要 一 个 接受 用 户 名 字 和 年 龄 的 简单 表单 。 这 个 类 可 以 这 样 来 定义 : 


# forms.py 
from django import forms 


class PersonDetailsForm(forms.Form): 
name = forms.CharField(max_length=100) 
age - forms.IntegerField() 


该 类 可 以 以 绑 定 或 者 不 绑 定 方式 来 初始 化 ， 一 如 下 面 代码 所 示 : 


>>> f = PersonDetailsForm() 

>>> print(f.as_p()) 

«p»«label for="id_name">Name:</label> «input id="id_name" maxlength="100" 
name="name" type="text" /></p> 

<p><label for="id_age">Age:</label> <input id="id_age" name="age" 
type-"number" /></p> 

>>> f.is bound 

False 

>>> g = PersonDetailsForm({"name": "Blitz", "age": "30"}) 

>>> print(g.as_p()) 

<p><label for="id_name">Name:</label> «input id="id_name" maxlength="100" 
name="name" type="text" value="Blitz" /></p> 

<p><label for="id_age">Age:</label> <input id="id_age" name="age" 
type-"number" value="30" /></p> 

>>> g.is_bound 

True 


要 注意 HTML 是 如 何 表 现 改 变 以 包括 它们 中 已 绑 定 数据 的 值 属性 。 


表单 可 以 只 在 你 创建 表单 对 象 时 才 被 绑 定 ， 即 ， 在 构造 器 中 。 用 户 如 何在 类 字典 对 象 的 最 后 
面 输入 每 个 表单 字段 的 值 ? 


要 想 解 决 这 个 问题 ， 你 需要 理解 用 户 是 如 何 与 表单 交互 的 。 在 下 面 的 的 图 表 中 ， 用 户 打开 用 
户 账户 表单 ， 首 先是 正确 地 填充 ， 并 提交 它 ， 然 后 用 有 效 信息 重新 提交 表单 : 


Django 





MyForm( ) 
GET /form/ 


Visits form page f > 


Returns empty form [fommobjas-p() — is_bound « False 


is. valid() * False 


























MyForm(request.POST) 
POST /form/ 
Submits form with errors ee Name itz 
Age Thirty 0) 
Returns form showing errors Le formobj.as_p() is. bound = True 
is. valid) * False 
MyFormírequest.POST) 


POST /form/ form.cleaned. data 


Submits valid form i Name Bitz ae — "Blitz" 
Age 0 | “age” 30 





Redirect /success/ 
Redirects to success page ”ose thie sas tc NU is. bound = True 


is. valid) = True 

















如 前 面 的 表单 所 示 ， 当 用 户 提交 表单 时 ， 在 request.POST ( 它 是 一 个 Querypict 的 实例 ) 内 
部 所 有 可 调用 的 视图 获取 到 全 部 的 表单 数据 。 表 单 使 用 类 字典 对 象 一 一 以 这 种 方式 引用 是 因 
为 它 的 行为 类 似 于 字典 ， 来 初始 ， 并 拥有 一 点 额外 的 功能 。 





表单 可 以 通过 两 种 不 同 的 方式 来 定义 以 发 送 数 据 表单 : GET 或 者 post 。 表 单 使 

用 METHOD=“GET” 定义 以 发 送 以 URL 编 码 的 表单 数据 ， 例 如 ， 当 你 提交 谷歌 搜索 时 ，URL 取 得 
表单 输入 ， 即 ， 搜 索 字 符 串 显 式 地 上 获 入 ， 比 如 9q-CatePictures 就 是 如 此 。 GET 方法 用 来 守 等 
表单 ， 它 不 会 对 世界 状态 做 出 任何 的 最 新 改变 。 (不 要 太 过 于 迁 腐 ， 多 次 处 理 有 同样 的 效果 

就 像 一 次 处 理 ) 。 大 多 数 情况 下 ， 这 意味 着 它 只 在 重新 取 回 数据 时 被 用 到 。 


不 过 ， 不 计 其 数 的 表单 都 是 使 用 METHOD="Post” 来 定义 的 。 这 样 ， 表 单数 据 会 一 直 发 送 HTTP 
请 求 的 主体 部 分 ， 而 且 它 们 对 于 用 户 来 说 是 不 可 见 的 。 它 们 被 用 于 任何 涉及 到 边际 效应 的 事 
情 ， 比 如 存储 或 者 更 新 数据 。 


视 你 所 定义 表单 类 型 的 不 同 ， 当 用 户 提交 表单 时 ， 视 图 会 重新 取 回 request.GET 或 
者 request.post 中 的 表单 数据 。 如 同 早 前 咱 么 提 到 的 那样 ， 它 们 中 的 哪 一 个 都 类 似 于 字典 。 
因此 ， 你 可 以 传递 它 到 表单 类 构造 器 以 获取 绑 定 的 form 对 象 。 

注释 


The Breach Steve was curled up and snoring heavily in his large three-seater couch. 
For the last few weeks, he had been spending more than 12 hours at the office, and 
tonight was no exception. His phone lying on the carpet beeped. t first, he said 
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soething incoherently, still deep in sleep. Then, it beeped again and again, in 
increasing urgency. 


By the fifth beep, teve awoke with a start. He frantically searched all over his couch, 
and finally located his phone. The screen showed a brightly colored bar chart. Every 
bar seemed to touch the high line except one. He pulled out his laptop and logged into 
the SuperBook server. The site was up and none of the logs indicated any unusual 
activity. However, the external services didn't look that good. 


The phone at the other end seemed to ring for eternity until a croaky voice answered, 
Hello, teve? Half an hour later, acob was able to ero down the proble to an 
unresponsive superhero verification service. Isn't that running on auron? asked 

teve. There was a brief hesitation. "| am afraid so," replied Jacob. 


Steve had a sinking feeling at the pit of his stomach. Sauron, a ainfrae application, 

was their first line of defense against cyber-attacks and other kinds of possible attack. It 
was three in the morning when he alerted the mission control team. Jacob kept chatting 
with him the whole time. He was running every available diagnostic tool. There was no 
sign of any security breach. 


Steve tried to calm him down. He reassured him that perhaps it was a temporary 
overload and he should get some rest. However, he knew that Jacob wouldn't stop until 
he found what's wrong. He also knew that it was not typical of Sauron to have a 
temporary overload. Feeling extremely exhausted, he slipped back to sleep. 


Next morning, as steve hurried to his office building holding a bagel, he heard a 
deafening roar. He turned and looked up to see a massive spaceship looming towards 
him. Instinctively, he ducked behind a hedge. On the other side, he could hear several 
heavy metallic objects clanging onto the ground. Just then his cell phone rang. It was 
Jacob. Something had moved closer to him. As Steve looked up, he saw a nearly 10- 
foot-tall robot, colored orange and black, pointing what looked like a weapon directly 
down at him. 


His phone was still ringing. He darted out into the open barely missing the sputtering 
shower of bullets around him. He took the call. "Hey Steve, guess what, | found out 
what actually happened." "I am dying to know," Steve quipped. 


"Remember, we had used UserHoller's form widget to collect customer feedback? 

pparently, their data was not that clean. | ean several serious exploits. Hey, there is 
a lot of background noise. Is that the T? Steve dived towards a large sign that said 
"Safe Assembly Point". "Just ignore that. Tell me what happened," he screamed. 
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"Okay. So, when our admin opened their feedback page, his laptop must have gotten 
infected. The worm could reach other systems he has access to, specifically, auron. | 
ust say acob, this is a very targeted attack. Someone who knows our security 
system quite well has designed this. | have a feeling something scary is coming our 


way. 


Across the lawn, a robot picked up an SUV and hurled it towards Steve. He raised his 
hands and shut his eyes. The spinning mass of metal froze a few feet above hi. 
Iportant call? asked Hexa as she dropped the car. Yeah, please get e out of 

here, teve begged. 


为 什么 数据 需要 清理 


终究 你 还 是 需要 从 表单 获取 “干净 的 数据 "。 这 是 否 意味 着 用 户 输 入 的 值 是 否 是 不 干净 的 呢 ? 是 
=e o 


首先 来 自 外 部 世界 的 任何 东西 都 不 应 该 一 开始 就 被 信任 。 恶 意 用 户 可 以 对 表单 输入 所 有 类 别 
的 探测 利用 ， 以 此 破坏 网 站 的 安全 。 因 此 ， 任 何 的 表单 数据 在 使 用 前 都 必须 被 净化 。 


提示 
Best Practice 任何 时 候 都 不 能 信任 用 户 的 输入 。 


第 二 ， request.post 或 者 request.GET 中 的 字段 值 只 是 字符 串 而 已 。 即 使 表单 字段 定义 为 整 
数 (比如 说 ， 年 龄 ) 或 者 日 期 (比如 说 ， 生 日 ) ， 浏 览 器 也 是 把 这 些 字段 以 字符 串 的 形式 发 
送 到 视图 。 不 可 避免 的 是 在 加 以 使 用 之 前 你 要 把 它们 转换 到 适当 的 Python 数据 类 型 。 form 类 
在 进行 清理 时 会 自动 地 达成 约定 。 


我 们 来 看 看 实际 的 例子 : 


>>> fill = {"name": "Blitz", "age": "30"} 
>>> g = PersonDetailsForm( fill) 
>>> g.is_valid() 
True 
>>> g.cleaned_data 
(agen sO; name :Blitz 
>>> type(g.cleaned_data["age"]) 
int 


年 龄 值 作为 字符 串 来 传递 (或 许 来 自 request.Posr ) 到 表单 类 。 验 证 之 后 ， 和 干净 数据 包含 整 


数 形式 的 年 龄 。 这 完全 符合 用 户 的 期 望 。 表 单 试图 抽象 出 字符 囊 的 传递 ， 以 及 对 用 户 给 出 可 
以 使 用 的 干净 的 Python 数 据 类 型 的 事实 。 


显示 表单 


Django 表 单 也 能 够 帮助 你 生成 表现 表单 的 HTML。 它 们 支持 脐 中 不 同 的 表现 形式 : asp ( 作 
为 段落 标签 ) ，as ul (显示 为 无 序列 表 项 ) ， 以 及 as table (意料 之 中 ， 显 示 为 表格 ) o 


模板 代码 生成 HTML 代 码 ， 浏 览 器 演 染 这 些 表 现 已 经 总 结 为 下 表 : 
图 片 : 略 


注意 HTML 表 现 仅 给 出 了 表单 字段 。 这 样 做 可 以 在 一 个 单独 的 HTML 表 单 中 轻松 地 包含 多 个 
Django 表 单 。 可 是 ， 这 样 做 也 意味 着 模板 设计 者 必须 有 点 儿 公 式 化 来 写 每 个 表单 ， 一 如 下 面 
代码 所 示 : 


«form method="post"> 
{% csrf_token %} 
<table>{{ form.as_table }}</table> 
«input type="submit" value="Submit" /> 
</form> 


注意 ， 为 了 使 HTML 完 整 的 表现 ， 你 需要 添加 form 标签 周 添加 CSRF 令 牌 环 ， table 或 
者 ul 标签 ， 以 及 submit 按钮 。 


是 使 用 crispy 的 时 候 了 


在 模板 中 写 这 么 多 公式 化 的 表单 是 很 无 聊 的 事情 。 django-crispy-forms 包 可 以 写 非 长 干脆 利 
落 的 来 写 表 单 模板 。 它 把 所 有 表现 和 布局 都 放 到 了 Django 表 单 自 身 。 因 此 ， 你 可 以 写 更 多 的 
Python 代码 ， 更 少 的 HTML ° 


下 面 的 表 展 示 了 csrispy 表 单 的 模板 标签 生成 更 加 完整 的 表单 ， 而 且 外 观 更 加 的 接近 原生 的 
Bootstrap 风 格 : 


Template Code 


{% <from method="post"><input type='hidden' name='csrfmiddlewaretoken' valu 


crispy form) | 了 简洁 而 删 去 余下 的 HTML) 


它 加 入 


ay 


那么 ， 你 是 如 何 实 现 更 加 干脆 利落 的 表单 的 ? 你 X django-crispy-forms 包 并 4 
到 INSTALLED_APPS 。 如 果 你 使 用 Bootstrap 3， 那 么 你 需要 在 设置 中 引用 : 


CRISPY_TEMPLATE_PACK = "bootstrap3" 


表单 初始 化 需要 引用 类 型 FormHelper 的 辅助 属性 。 下 面 的 代码 以 最 小 化 设计 ， 并 使 用 默认 的 
布局 : 


from crispy_forms.helper import FormHelper 
from crispy_forms.layout import Submit 


class PersonDetailsForm(forms.Form): 
name = forms.CharField(max_length=100) 
age = forms.IntegerField() 


def anit eseli sargs, kwargs): 
super().__init__(*args, **kwargs) 
self.helper = FormHelper(self) 
self.helper.layout.append(Submit('submit', 'Submit')) 


理解 CSRF 


你 也 一 定 注 意 到 了 在 表单 模板 中 叫做 csRF 的 东西 。 它 用 来 干什么 的 ? 它 是 一 种 应 对 针对 表单 
的 跨 站 请 求 伪造 (CSRF) 的 保护 机 制 。 


它 通过 注入 服务 端 生成 的 随机 的 叫做 CSRF 令 牌 的 字符 工作 ， 这 个 字符 串 对 用 户 的 Session 来 
说 是 唯一 的 。 每 次 表单 提交 时 ， 都 有 一 个 包含 此 令 牌 的 隐藏 字段 。 这 个 令 牌 确保 表单 是 由 用 
户 生 成 而 且 是 来 自 原始 站 点 的 ， 而 不 是 由 攻击 者 使 用 类 似 字段 创建 的 假冒 表单 。 


在 表单 使 用 GET 方法 时 并 不 推荐 CSRF 令 牌 ， 因 为 GET 行为 不 应 该 改变 服务 器 状态 。 此 外 ， 
表单 通过 GET 提交 表单 会 在 URL 中 暴露 CSRF 令 牌 。 因 此 URL 在 登录 或 者 并 行 噢 探 时 有 具有 更 
高 的 风险 ， 当 使 用 post 方式 最 好 在 表单 中 使 用 CSRF 。 


表单 处 理 类 视图 
基本 上 ， 我 们 可 以 通过 子 类 化 类 视图 来 处 理 表单 : 


class ClassBasedFormView(generic.View): 
template name = 'form.html' 
def; get(self, request); 
form = PersonDetailsForm() 
return render(request, self.template_name, {'form': form}) 
defi post(self, request): 
form = PersonDetailsForm( request .POST) 
if form.is_valid(): 
， 我 就 可 以 使 用 了 form.cleaned_data 
return redirect (successi) 
else: 


无 效 ， 重 新 显示 含有 错误 高 高 的 表单 
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成 功 的 话 


return render (request, self.template_name, 
{'form': form}) 


上 面 的 代码 与 我 们 之 前 的 见 到 的 序列 图 表 相 比较 。 三 种 应 用 场景 已 经 被 分 别处 理 。 


每 一 个 表单 都 如 期 望 的 那样 遵守 了 模式 。 如 果 提 交 的 表单 发 现 是 无 效 
的 ， 它 必须 发 起 一 个 重 定向 。 这 能 够 阻止 重复 表单 的 提交 。 


不 过 ， 这 样 做 是 并 不 十 分 符合 DRY 原 则 的 编写 。 表 单 类 名 称 和 模板 名 称 属性 都 已 经 重复 了 。 
使 用 Formview 这 样 的 通用 类 视图 能 够 表单 处 理 中 的 宛 余 部 分 。 下 面 的 代码 会 给 你 带 来 和 前 面 
一 样 的 功能 而 且 还 少 了 几 行 代码 : 


from django.core.urlresolvers import reverse_lazy 


class GenericFormView(generic.FormView): 
template name = 'form.html' 
form class - PersonDetailsForm 
success url = reverse lazy("success") 


这 个 例子 中 我 们 需要 使 用 reverse lazy ， 因 为 URL 模 式 在 视图 文件 导入 时 并 没有 被 载 入 。 


表单 模式 


我 们 来 看 一 看 使 用 表单 时 会 见 到 的 一 些 常用 模式 。 


模式 -动态 表单 的 生成 
问题 : 自动 地 添加 表单 字段 或 者 改变 已 经 声明 的 表单 字段 。 


解决 方案 : 在 表单 初始 化 的 时 候 添 加 或 者 改变 字段 。 


问题 细节 


表单 通常 以 一 种 将 拥有 的 字段 列 为 类 字段 的 声明 方式 。 不 过 ， 有 时 候 我 们 不 能 提前 知道 数 
量 ， 或 者 这 些 字段 的 类 型 。 这 就 要 求 表单 能 够 动态 地 生成 。 该 模式 有 时 称 为 动态 表单 或 
者 运行 时 的 表单 生成 。 


想象 有 一 个 旅客 航班 登录 系统 ， 它 允许 经 济 稻 机 票 改 签 为 头等 般 。 假 如 头等 般 座 席 有 剩余 ， 
那么 在 用 户 想 要 乘坐 头等 舱 是 就 需要 有 一 个 额外 的 选项 。 不 过 ， 这 个 额外 的 字段 不 能 够 公 
开 ， 因 为 它 对 于 全 部 用 户 来 说 是 不 可 见 的 。 这 样 的 动态 表单 就 可 以 通过 该 模式 来 处 理 。 


解决 方案 细节 


每 一 个 表单 的 实例 都 有 一 个 叫做 字段 的 fields ， 它 是 一 个 拥有 全 部 字段 的 字典 。 可 以 在 运行 
时 对 它 作 出 修改 。 添 加 或 者 改变 字段 可 以 在 表单 初始 化 时 完成 。 


例如 ， 如 果 我 们 添加 一 个 到 用 户 详情 表单 的 复 选 框 ， 只 要 在 表单 初始 化 时 命名 为 “Upgrade” 的 
关键 字 参 数 为 夏 ， 那 么 我 们 就 可 以 以 如 下 代码 来 实现 它 : 


class PersonDetailsForm(forms.Form): 
name = forms.CharField(max length-100) 
age - forms.IntegerField() 
def imit (self, sargs, **kwangs): 
upgrade = kwargs.pop("upgrade", False) 
super(). init (*args, mp d 
# Show first class option? 显示 头等 般 选 项 ? 
if upgrade: 
self.fields["first_class"] = forms.BooleanField(label="Fly First Class?") 


现在 ， 我 们 只 需要 传递 关键 字 参 数 PersonDetailsForm(upgrade-True) 以 产生 一 个 额外 的 布尔 输 
入 字段 ( 复 选 框 ) 。 


注释 
注意 ， 最 新 引入 的 关键 字 参 数 在 我 们 调用 super 以 避免 unexpected keyword 错误 已 经 被 
移 除 ， 或 者 去 掉 。 


如 果 我 们 对 这 个 例子 使 用 Formview X > AA 我 们 需要 通过 重 写 视图 类 的 get_form_kwargs 方 
法 来 传递 关键 字 参 数 ， 一 如 下 面 代码 所 示 : 


class PersonDetailsEdit(generic.FormView): 
def get form kwargs(self): 
kwargs = super().get form kwargs() 


kwargs["upgrade"] = True 
return kwargs 


这 个 模式 可 以 用 来 在 运行 时 改变 任意 一 个 字段 的 属性 ， 比 如 它 的 部 件 或 者 辅助 文本 。 它 也 能 
够 用 于 模型 表单 。 


在 很 多 情况 下 ， 外 观 所 需 的 动态 表单 可 以 通过 使 用 Django 表 单 集合 来 解决 。 在 页 面 中 当 表 单 
需要 重复 时 就 要 用 到 它们 了 。 一 个 典型 的 表单 集合 用 法 是 在 设计 数据 的 网 格 视图 时 一 行 接 一 
行 的 添加 元 素 。 因 此 ， 你 不 需要 使 用 任意 数量 的 行 来 创建 一 个 动态 表单 。 你 只 需 依 照 行 来 创 
建 表单 ， 使 用 formset_factory 函数 来 创建 多 个 行 。 


英 式 -用 户 表 单 
问题 : 表单 需要 根据 已 经 登录 的 用 户 来 进行 定制 。 
解决 方案 : 传递 已 登录 用 户 作为 关键 字 参 数 到 表单 的 构造 器 。 
问题 细节 
表单 可 以 按 用 户 以 不 同 的 形式 来 表现 。 某 些 用 户 或 许 不 需要 填充 全 部 字段 ， 而 其 他 人 就 需要 


添加 额外 的 信息 。 某 些 情况 下 ， 你 或 许 需 要 对 用 户 资 格 做 些 检查 ， 比 如 ， 验 证 他 们 是 否 为 一 
个 组 的 成 员 ， 以 便 搞 清楚 如 何 构建 表单 。 


解决 方案 细节 


你 一 定 注意 到 了 ， 你 可 以 使 用 动态 表单 生成 模式 中 给 出 的 解决 方案 来 解决 这 个 问题 。 你 只 需 

要 将 request.user 作为 一 个 关键 字 参 数 传递 到 表单 。 然 而 ， 为 了 简洁 和 更 富 于 重复 使 用 的 解 
决 方案 ， 我 们 也 可 以 使 用 django-braces 包 中 的 mixin 。 

如 前 面 的 例子 所 示 ， 我 们 需要 对 用 户 展示 一 个 额外 的 复 选 框 。 可 是 ， 这 仅 在 用 户 是 VIP 组 成 员 
时 才 会 被 显示 。 让 我 们 来 看 看 PersonpetailsForm 是 如 何 使 用 django-braces 的 表单 


mixin UserkwargModelFormMixin 来 简化 的 : 
from braces.forms import UserKwargModelFormMixin 


class PersonDetailsForm(UserKwargModelFormMixin, forms.Form): 


def init (self, *args, **kwargs): 
super(). init (*args, **kwargs) 
# Are you a member of the VIP group? 
# 你 是 VIP 组 的 成 员 吗 ? 
ai sue, user.groups.filter(name="VIP").exists(): 
self.fields["first_class"] = forms.BooleanField(label="Fly First Class?") 


注意 self.user 如 何 通过 mixin 去 掉 用 户 关 键 字 参 数 被 自动 地 设 为 可 用 。 


对 应 到 表单 mixin， 有 一 个 成 为 UserFormkwargsMixin 的 视图 mixin， 它 需要 添加 到 视图 ， 使 
用 LoginRequiredMixin 以 确保 只 有 已 经 登录 的 用 户 可 以 访问 该 视图 : 


class VIPCheckFormView(LoginRequiredMixin, UserFormKwargsMixin, 
generic.FormView): 
form class - PersonDetailsForm 


现在 用 户 参数 自动 地 传递 到 表单 PersonbetailsForm ° 


在 django-braces 中 检查 其 他 的 表单 mixin， 比 如 拿 FormValidMessageMixin 来 说 ， 它 就 是 常见 
的 表单 使 用 模式 的 一 个 现成 的 方案 。 


模式 -一 个 视图 的 多 个 表单 行为 
问题 : 在 一 个 独立 的 视图 或 者 页 面 中 处 理 多 个 表单 行为 。 
解决 方案 : 表单 可 以 使 用 独立 的 视图 来 处 理 表单 提交 ， 或 者 识别 基于 提交 按钮 名 称 的 表单 。 


问题 细节 


Django 使 合并 多 个 拥有 相同 行为 的 表单 相当 地 简单 ， 例 如 ， 单 独 的 一 个 提交 按钮 。 不 过 ， 大 
多 数 的 页 面 需要 在 同样 的 页 面 上 显示 多 个 行为 。 例 如 ， 你 或 许 想 要 用 户 在 同一 页 面 的 两 个 不 
同 表 单 中 订阅 或 取消 订阅 一 个 新 闻 简 报 。 

不 过 ，Dijango 的 Formview 被 设计 成 只 处 理 一 个 表单 对 应 一 个 视图 的 场景 。 很 多 的 其 他 通用 类 
视图 也 共享 该 假定 。 


解决 方案 细节 
处 理 多 个 表单 有 两 个 办 法 : 分 离 视图 和 独立 视图 。 首 先 我 们 来 看 下 第 一 个 方法 。 


独立 的 行为 分 离 视图 


依据 视图 的 行为 为 每 个 表单 指定 不 同 的 视图 ， 是 一 个 相当 简单 的 办 法 。 人 例如， 订阅 和 取消 订 
阅 表 单 。 刚 好 有 两 个 独立 的 视图 类 来 处 理 他 们 各 自 表 单 的 PosT 方法 。 


独立 的 相同 视图 


可 能 你 发 现 了 分 割 视图 来 处 理 表 单 是 没有 必要 的 ， 抑 或 发 现 了 使 用 一 个 公共 视图 来 处 理 逻 辑 
上 相关 连 的 表单 为 更 加 简洁 明了 。 


当 对 多 个 表单 使 用 相同 的 视图 类 时 ， 其 挑战 在 于 标识 哪个 表单 来 处 理 POST 行 为 。 这 里 ， 我 们 
利用 了 事实 上 的 优势 ， 提 交 按 钮 的 名 称 和 值 同 时 被 提交 了 。 假 如 提交 按钮 在 表单 中 命名 唯 
一 ， 那 么 处 理 时 表单 就 可 以 被 标识 出 来 。 


这 里 ， 我 们 定义 一 个 使 用 crispy 表 单 的 订阅 器 ， 这 样 我 们 就 可 以 的 命名 提交 按钮 了 : 


class SubscribeForm(forms.Form): 
email - forms.EmailField() 


def init__(self, *args, **kwatgs): 
super().__init__(*args, **kwargs) 
self.helper = FormHelper(self) 
self.helper.layout.append(Submit('subscribe butn', 'Subscribe')) 


取消 订阅 表单 类 unsubscribeForm 以 完全 相同 的 方式 来 定义 (因此 ， 这 里 我 们 就 省 略 不 写 出 来 
1) > WT submit 按钮 被 命名 为 unscribe butn 之 外 。 


因为 Formview 被 设计 成 单 视图 ， 我 们 会 使 用 一 个 简单 的 类 视图 ， 即 ， TemplageView ， 来 做 为 
视图 的 基 类 。 我 们 来 看 一 看 视图 定义 以 及 get 方法 : 


from .forms import SubscribeForm, UnSubscribeForm 


class NewsletterView(generic.TemplateView) : 
subcribe_form_class = SubscribeForm 
unsubcribe form class = UnSubscribeForm 
template name - "newsletter.html" 


def get(self, request, *args, **kwargs): 
kwargs.setdefault("subscribe form", self.subcribe form class()) 
kwargs.setdefault("unsubscribe form", self.unsubcribe form class()) 
return super().get(request, *args, **kwargs) 


TemplateView 类 的 关键 字 参 数 可 以 方便 地 插入 进 模板 上 下 文 。 我 们 仅 在 表单 实例 不 存在 时 ， 
利用 setdefault 字典 方法 的 帮助 来 创建 其 中 一 个 表单 的 实例 。 我 们 很 快 就 可 以 看 到 为 什么 要 
这 样 做 。 


接 下 来 ， 我 们 来 看 看 POST 方法 ， 它 处 理 了 表单 的 提交 : 


def post(self, request, *args, **kwargs): 
form_args = { 
'data': self.request.POST, 
'files': self.request.FILES, 


} 


if "subscribe butn" in request. POST: 
form = self.subcribe form class(**form args) 
if not form.is valid(): 
return self.get(request, 
subscribe form-form) 
return redirect("success formi") 
elif "unsubscribe butn" in request.POST: 
form = self.unsubcribe form class(**form args) 
if not form.is valid(): 
return self.get(request, 
unsubscribe form-form) 
return redirect("success form2") 
return super().get(request) 


首先 ， 表 单 的 关键 字 参 数 ， 比 如 数据 和 文件 ， 就 是 在 form_args 字典 中 产生 的 。 接 下 来 ， 第 
一 个 表单 的 submit 按钮 的 存在 是 用 来 检查 request.post 。 假 如 发 现 了 按钮 的 名 称 ， 那 么 第 一 
个 表单 就 被 初始 化 。 


如 果 表 单 验证 失败 ， 那 么 响应 通过 第 一 个 表单 实例 的 GET 方法 被 创建 的 方法 就 会 返回 。 同 样 
地 ， 我 们 查找 第 二 个 表单 的 提交 按钮 以 检查 第 二 个 表单 是 否 被 提交 。 


相同 视图 中 的 相同 表单 的 实例 可 以 通过 表单 前 级 以 相同 方式 来 实现 。 你 可 以 使 
用 subscribeForm(prefix="offers") 这 样 的 前 级 参数 来 实例 化 一 个 表单 。 上 比如 实例 利用 给 出 的 
参数 作为 前 缓 加 入 到 所 有 的 表单 字段 ， 实 际 上 当 作 一 个 表单 的 命名 空间 来 使 用 。 
AL E > 
模式 -CRUD 视 图 
问题 : 公式 化 的 对 模型 编写 CRUD 接 口 是 在 重复 相同 的 事 。 


解决 方案 : 使 用 类 的 通用 视图 来 编辑 视图 。 


问题 细节 


在 大 多 数 的 web 应 用 中 ， 大 约 百 分 之 80 的 时 间 被 用 来 写 ， 创 建 ， 读 取 ， 更 新 以 及 删除 
(CRUD) 数据 库 的 接口 。 例 如 ， 基 本 上 ，Twitter 就 涉及 到 了 创建 和 读 取 其 他 用 户 的 推 文 。 这 
里 ， 推 文 是 可 以 被 维护 和 存储 的 数据 库 对 象 。 


要 是 从 零 开 始 写 这 样 的 接口 实在 是 乏味 至 极 。 如 果 CRUD 接 口 可 以 自动 地 从 模型 类 创建 ， 那 么 
这 个 模式 可 以 轻松 地 管理 。 


解决 方案 细节 


Django 利 用 了 一 个 四 个 通用 类 视图 的 组 简化 了 创建 CRUD 视 图 的 过 程 。 如 下 ， 它 们 可 以 被 映 
射 到 其 自身 像 对 应 的 操作 : 


e CreateView: 该 视图 显示 一 个 空白 表单 以 创建 一 个 新 的 对 象 。 
。 DetailView: 该 视图 通过 读 取 数 据 库 来 展示 一 个 对 象 的 细节 。 
e UpdateView: 该 视图 被 允许 通过 一 个 预先 生成 的 表单 来 更 新 一 个 对 象 的 细节 。 
e DeleteView: 该 视图 像 是 一 个 确认 页 面 ， 并 准许 删除 对 象 。 


让 我 们 来 看 一 个 简单 的 例子 。 我 们 拥有 一 个 包含 重要 日 期 的 模型 ， 它 关系 到 使 用 网 站 的 每 一 
个 用 户 的 利益 。 我 们 需要 构建 简单 的 CRUD 接 口 ， 这 样 任何 人 都 可 以 查看 ， 修 改 这 些 日 期 。 我 
们 来 看 下 Importantdate 模型 的 内 容 : 


# models.py 
class ImportantDate(models.Model): 
date = models.DateField() 
desc = models.CharField(max_length=100) 
def get_absolute_url(self): 
return reverse('impdate_detail', args=[str(self.pk)]) 


get absolute url() 方法 被 Createview 和 UpdateView 类 在 对 象 成 功 创建 或 者 更 新 之 后 使 用 
它 已 经 被 路 由 到 了 对 象 的 petailview ° 


这 些 CRUD 视 图 足够 的 简单 ， 因 此 它们 不 解 自 明 的 ， 一 如 以 下 代码 所 示 : 


# Views ,py 
from django.core.urlresolvers import reverse_lazy 
from . import forms 


class ImpDateDetail(generic.DetailView): 
model = models.ImportantDate 


class ImpDateCreate(generic.CreateView): 
model = models.ImportantDate 
form class = forms. ImportantDateForm 


class ImpDateUpdate(generic.UpdateView) : 
model = models.ImportantDate 
form_class = forms.ImportantDateForm 


class ImpDateDelete(generic.DeleteView): 
model = models.ImportantDate 
Success url = reverse_lazy("impdate_list") 


这 些 通用 视图 中 ， 模 型 类 只 是 强制 成 员 被 引用 。 不 过 ， 在 Deleteview 的 情形 
下 ， success_url 函数 需要 很 好 地 的 应 用 。 这 是 因为 get absolute url 删除 之 后 再 也 不 能 够 用 
来 找到 在 什么 地 方 重 定 向 用 户 。 


定义 form class 属性 并 非 是 强制 的 。 如 果 它 被 省 略 ， 与 ModelForm 方法 相当 的 模型 会 被 创 
建 。 不 过 ， 我 们 想 要 创建 自己 的 模型 表单 以 利用 crispy 表 单 ， 一 如 下 面 代码 所 示 : 


# forms.py 

from django import forms 

from . import models 

from crispy_forms.helper import FormHelper 
from crispy_forms.layout import Submit 


class ImportantDateForm(forms.ModelForm) : 

class Meta: 
model = models.ImportantDate 
fields = ["date", "desc"] 

der eanit seln “args. = kwanrgs): 
super().__init__(*args, **kwargs) 
self.helper = FormHelper(self) 
self.helper.layout.append(Submit('save', 'Save')) 


要 感谢 crispy 表 单 ， 我 们 在 模板 中 需要 非常 少 的 HTML 装 饰 以 构建 这 些 CRUD 表 单 。 


HHH 注释 注意 明确 地 引用 wodelForm 方法 的 字段 就 是 最 佳 实践 ， 在 未 来 的 发 行 版 中 
这 也 将 成 为 强制 规定 。 


默认 ， 模 板 的 路 径 基于 视图 类 和 模型 的 名 称 。 为 了 简洁 起 见 ， 此 处 我 们 省 略 了 模板 的 源码 。 
注意 我 们 可 以 对 createview 和 updateview 使 用 相同 的 表单 。 


， 我 们 来 看 看 urls.py ， 这 里 所 有 东西 都 连接 起 来 了 : 


url(r'^impdates/create/$', 
pviews.ImpDateCreate.as view(), name-"impdate create"), 
url(r'Aimpdates/(?P<pk>\d+)/$', 
pviews.ImpDateDetail.as_view(), name="impdate_detail"), 
url(r'Aimpdates/(?P<pk>\d+)/update/$', 
pviews.ImpDateUpdate.as view(), name="impdate_update"), 
url(r'^impdates/(?P«pk»Nd*)/delete/$', 
pviews.ImpDateDelete.as view(), name-"impdate delete"), 


Dijango 的 通用 是 我 们 开始 为 模型 创建 CRUD 视 图 的 一 种 了 不 起 的 方式 。 仅 需 少 少 几 行 代码 ， 
你 就 可 以 获得 经 过 良好 测试 的 模型 表单 和 视图 ， 而 不 用 自己 来 做 重复 乏味 的 工作 。 


E 
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在 这 一 章 ， 我 们 见 过 了 web 表 单 如 何 被 创建 ， 以 及 在 Django 中 如 何 利 用 表单 类 将 它们 抽象 。 
我 们 也 即 拿 过 了 在 使 用 表单 时 ， 利 用 多 种 技术 和 模式 去 节省 时 间 。 

在 下 一 章 ， 我 们 来 看 一 看 在 使 用 旧版 本 的 Django 代 码 库 时 用 到 的 系统 化 的 方法 ， 以 及 当 我 们 
碰 到 用 户 需要 时 如 何 的 加 强 它 。 


第 和 八 章 -处 理 旧 版 本 代码 


在 本 章 我 们 将 讨论 一 下 话题 : 


。 阅读 Django 代码 

e 探索 相关 文档 

。 增 量 变更 还 是 完全 重 写 
改变 代码 之 前 编写 测试 
旧版 本 数据 库 的 集成 


It sounds exciting when you are asked to join a project. Powerful new tools and cutting-edge 
technologies might await you. However, quite often, you are asked to work with an existing, 
possibly ancient, codebase. 


加 入 项 目 时 你 可 能 很 感 兴 趣 。 


To be fair, Django has not been around for that long. However, projects written for older 
versions of Django are sufficiently different to cause concern. oeties, having the entire 
source code and documentation might not be enough. 

公平 起 见 ，Django 并 没有 一 直 这 样 做 。 不 过 ， 项 目 


Yeah, said Brad, Where is Hart? Mada hesitated and replied, "Well, he resigned. 

Being the head of IT security, he took moral responsibility of the perimeter breach." Steve, 
evidently shocked, was shaking his head. "| am sorry," she continued, "But | have been 
assigned to head SuperBook and ensure that we have no roadblocks to meet the new 
deadline." 


There was a collective groan. Undeterred, Madam O took one of the sheets and began, "It 
says here that the Remote Archive module is the most high-priority item in the incomplete 
status. | believe Evan is working on this." If you are asked to recreate the environment, then 
you might need to fumble with the configuration, database settings, and running services 
locally or on the network. There are so many pieces to this puzzle that you might wonder 
how and where to start. 


Understanding the Django version used in the code is a key piece of information. As Django 
evolved, everything from the default project structure to the recommended best practices 
have changed. Therefore, identifying which version of Django was used is a vital piece in 
understanding it. 


Django 设计 模式 与 最 佳 实践 


理解 Django 的 版 本 再 代码 中 的 使 用 是 很 关键 的 信息 。 随 着 Django 的 进化 ， 所 有 来 自 默认 项 目 
结构 的 建议 最 佳 实践 都 发 生 了 变化 。 因 此 ， 认 出 Django 在 使 用 的 是 哪 一 个 版 本 是 理解 这 个 框 
架 中 重要 的 一 环 。 


Change of Guards 


Sitting patiently on the ridiculously short beanbags in the training room, the SuperBook 
team waited for Hart. He had convened an emergency go-live meeting. Nobody 
understood the "emergency" part since go live was at least 3 months away. 


Madam O rushed in holding a large designer coffee mug in one hand and a bunch of 
printouts of what looked like project timelines in the other. Without looking up she said, 
"We are late so | will get straight to the point. In the light of last week's attacks, the 
board has decided to summarily expedite the SuperBook project and has set the 
deadline to end of next onth. ny questions? 


Yeah, said Brad, Where is Hart? Mada hesitated and replied, "Well, he 

resigned. Being the head of 1T security, he took moral responsibility of the perimeter 
breach." Steve, evidently shocked, was shaking his head. "| am sorry," she continued, 
"But | have been assigned to head SuperBook and ensure that we have no roadblocks 
to meet the new deadline." 


There was a collective groan. Undeterred, Madam O took one of the sheets and began, 
"It says here that the Remote Archive module is the most high-priority item in the 
incomplete status. | believe Evan is working on this." 


"That's correct," said Evan from the far end of the room. "Nearly there," he smiled at 
others, as they shifted focus to him. Madam O peered above the rim of her glasses and 
smiled almost too politely. "Considering that we already have an extremely well-tested 
and working Archiver in our Sentinel code base, | would recommend that you leverage 
that instead of creating another redundant system." 


"But," Steve interrupted, "it is hardly redundant. We can improve over a legacy archiver, 
can't we? If it isn't broken, then don't fix it, replied Madam O tersely. He said, "He 

is working on it," said Brad almost shouting, What about all that work he has already 
finished? 


van, how uch of the work have you copleted so far? asked , rather 
impatiently. "About 12 percent," he replied looking defensive. veryone looked at hi 
incredulously. What? That was the hardest percent" he added. 


O continued the rest of the meeting in the same pattern. Everybody's work was 
reprioritied and shoehorned to fit the new deadline. s she picked up her papers, 
readying to leave she paused and removed her glasses. 
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"| know what all of you are thinking... literally. But you need to know that we had no 
choice about the deadline. All | can tell you now is that the world is counting on you to 
meet that date, somehow or other." Putting her glasses back on, she left the room. 


"| am definitely going to bring my tinfoil hat," said Evan loudly to himself. 


查找 Django 的 版 本 信息 


理论 上 ， 每 个 项 目 在 根 目 录 都 拥有 一 个 requirements.txt 文 件 ， 或 者 一 个 setup.py 文 件 ， 这 个 
文件 将 表明 Django 再 项 目 中 要 使 用 的 是 哪 一 个 版 本 。 让 我 们 来 看 看 于 此 相关 的 文件 片段 : 


Django==1.5.9 


注意 ， 版 本 数字 已 经 完全 提 过 了 的 称 作 链 (相对 于 Django>=1.5.9) 。 对 每 一 个 包 都 进行 链接 
是 一 个 好 习惯 ， 因 为 它 能 够 减少 人 们 的 疑问 ， 让 你 更 为 确定 版 本 信息 。 
Unfortunately, there are real-world codebases where the requirements.txt file was not 


updated or even completely missing. In such cases, you will need to probe for various 
telltale signs to find out the exact version. 


不 丰 的 是 ， 


激活 虚拟 环境 


In most cases, a Django project would be deployed within a virtual environment. Once you 
locate the virtual environment for the project, you can activate it by jumping to that directory 
and running the activated script for your OS. For Linux, the command is as follows: 


再 很 多 情况 下 ，Dijango 的 项 目 会 部 署 在 一 个 虚拟 环境 中 。 一 旦 你 找 出 了 项 目的 虚拟 环境 ， 你 
可 以 通过 跳 过 这 个 目录 ， 并 为 系统 运行 激活 的 脚本 。 对 于 Linux 来 说 ， 可 以 使 用 如 下 命令 : 


$ source venv_path/bin/activate 


Once the virtual environment is active, start a Python shell and query the Django version as 
follows: 


只 要 虚拟 环境 一 激活 ， 你 就 可 以 启动 Python 终端 ， 然 后 像 我 这 样 查询 Django 的 版 本 : 


$ python 

>>> import django 

>>> print(django.get_version()) 
Oa 


The Django version used in this case is Version 1.5.9. 
本 例 中 使 用 的 Django 版 本 是 1.5.9. 
Alternatively, you can run the manage.py script in the project to get a similar output: 


可 选择 的 是 ， 你 可 以 在 项 目 中 运行 脚本 manage.py 以 获取 类 似 的 输出 内 容 : 


$ python manage.py --version 
abo 


However, this option would not be available if the legacy project source snapshot was sent 
to you in an undeployed form. If the virtual environment (and packages) was also included, 
then you can easily locate the version number (in the form of a tuple) in the _ init .py file 
of the Django directory. For example: 


不 过 呢 ， 要 是 在 未 部 署 的 情况 下 ， 之 前 遗留 的 项 目 源 码 镜 像 被 发 送 给 你 了 ， 那 么 这 个 选项 是 
不 可 用 的 。 如 果 庶 拟 环 境 〈 以 及 包 ) 被 包括 在 内 ， 那 么 你 在 Django 目 录 中 的 _init_.py X 
件 简单 地 找到 版 本 号 (以 元 组 地 形式 出 现 ) 。 例 如 : 


$ cd envs/foo env/lib/python2.7/site-packages/django 
$ cat _ init .py 
VERSION = (1, 5, 9, 'final', 0) 


If all these methods fail, then you will need to go through the release notes of the past 
Django versions to deterine the identifiable changes form exaple, the 
AUTH_PROFILE_MODULE setting was deprecated since Version 1.5) and match them to 
your legacy code. Once you pinpoint the correct Django version, then you can move on to 
analyzing the code. 


如 果 ， 所 有 这 些 方 法 都 不 管用 ， 那 么 你 需要 


文件 都 放 在 哪里 了 ? 这 可 不 是 PHP 啊 


最 大 的 一 个 困难 点 是 用 到 的 场合 ， 特 别 是 如 果 你 来 自 PHP 或 者 APS.NET 的 世界 ， 即 ， 源 文件 
并 不 位 于 web 服 务 器 的 文档 根 目 录 ， 而 目录 却 通常 命名 为 wwwroot 或 者 public html 。 此 外 ， 
代码 的 目录 结构 和 网 站 的 URL 结 构 之 间 并 没有 直接 的 关系 。 


In fact, you will find that your Django website's source code is stored in an obscure path 
such as /opt/webapps/my-django-app. Why is this? ong any good reasons, it is often 
ore secure to ove your confidential data outside your public webroot. This way, a web 
crawler would not be able to accidentally stumble into your source code directory. 


实际 上 ， 你 会 发 现 自己 的 Django 站 点 源码 被 存储 在 了 一 个 使 人 难以 理解 的 的 路 径 中 ， 比 
如 ，/opt/webapps/my-django-app。 为 什么 会 这 样 ? 


As you would read in the Chapter 11, Production-ready the location of the source code can 
be found by exaining your web server's configuration file. Here, you will find either the 
environment variable DJANGO SETTINGS MODULE being set to the module's path, or it 
will pass on the request to a WI server that will be configured to point to your project. wsgi 
file. 

和 你 之 前 在 第 十 一 章 读 到 的 那样 ， 


Starting with urls.py 


Even if you have access to the entire source code of a Django site, figuring out how it works 
across various apps can be daunting. It is often best to start from the root urls.py URLconf 
file since it is literally a ap that ties every request to the respective views. 


即使 你 访问 了 整个 Django 站 点 的 源 代码 ， 要 摘 清 楚 url 如 何 与 多 个 应 用 交互 是 令 人 辟 惧 的 。 


With normal Python programs, | often start reading from the start of its execution 一 say, from 
the top-level main module or wherever the main check idiom starts. In the case of Django 
applications, | usually start with urls.py since it is easier to follow the ow of execution 

based on various URL patterns a site has. 


In Linux, you can use the following find command to locate the settings.py file and the 
corresponding line specifying the root urls.py: 


$ find . -iname settings.py -exec grep -H 'ROOT_URLCONF' {} \; 
./projectname/settings.py:ROOT URLCONF = 'projectname.uris' 

$ ls projectname/urls.py 

projectname/urls.py 


Jumping around the code Reading code sometimes feels like browsing the web without the 
hyperlinks. When you encounter a function or variable defined elsewhere, then you will need 
to jup to the file that contains that definition. oe IDs can do this autoatically for you 

as long as you tell it which files to track as part of the project. 


If you use Emacs or Vim instead, then you can create a TAGS file to quickly 

navigate between files. Go to the project root and run a tool called Exuberant Ctags as 
follows: 

如 果 你 使 用 的 是 Emacs 或 者 Vim， 那 么 你 可 以 创建 一 个 TAG 文件 来 快速 地 在 多 个 文件 之 间 进 行 
浏览 。 如 下 ， 切 换 目 录 到 根 目 录 ， 然 后 运行 叫做 EXxuberant Ctagst) LH : 


find . -iname "*.py" -print | etags - 


This creates a file called TAGS that contains the location inforation, where every 

syntactic unit such as classes and functions are defined. In Emacs, you can find the 
definition of the tag, where your cursor or point as it called in acs is at using the M-. 
command. 


While using a tag file is extreely fast for large code bases, it is quite basic and is not aware 
of a virtual environent where ost definitions ight be located. n excellent alternative 

is to use the elpy package in acs. It can be configured to detect a virtual environent. 

uping to a definition of a syntactic eleent is using the same M-. coand. However, the 
search is not restricted to the tag file. o, you can even jup to a class definition within the 
Django source code sealessly. 


Understanding the code base 


It is quite rare to find legacy code with good documentation. Even if you do, the 
documentation might be out of sync with the code in subtle ways that can lead to further 
issues. Often, the best guide to understand the application's functionality is the executable 
test cases and the code itself. 


The official Django docuentation has been organied by versions at — https://docs. 
djangoproject.com. On any page, you can quickly switch to the corresponding page in the 
previous versions of Django with a selector on the bottom right-hand section of the page: 


图 片 : 略 


In the same way, documentation for any Django package hosted on readthedocs. org can 
also be traced back to its previous versions. For example, you can select the documentation 
of django-braces all the way back to v1.0.0 by clicking on the selector on the bottom left- 
hand section of the page: 


图 片 : 略 


Creating the big picture 描绘 宏伟 蓝图 


Most people find it easier to understand an application if you show them a high-level 
diagram. While this is ideally created by someone who understands the workings of the 
application, there are tools that can create very helpful high-level depiction of a Django 
application. 


很 多 人 发 现 如 果 你 对 他 们 展示 一 个 高 级 图 表 ， 那 么 他 们 会 觉得 更 容易 理解 一 个 应 用 。 而 这 个 
图 表 ， 理 论 上 是 由 那些 理解 应 用 工作 流程 的 人 所 创建 ， 有 很 多 工具 可 以 创建 非常 富有 帮助 的 
对 Django 应 用 的 高 级 描述 。 


A graphical overview of all models in your apps can be generated by the graph models 
management command, which is provided by the django-command-extensions package. As 
shown in the following diagram, the model classes and their relationships can be understood 
at a glance: 


应 用 里 的 全 部 模型 的 图 形 化 的 概览 都 可 以 通过 管理 命令 graph_models 生 成 ， 它 通过 包 django- 
command-extensions 实 现 。 如 下 图 所 示 ， 模 型 类 以 及 这 些 模型 之 间 的 关系 都 可 以 一 目 了 然 : 


图 片 : 略 


Model classes used in the SuperBook project connected by arrows indicating their 
relationships 


This visualization is actually created using PyGraphviz. This can get really large for projects 
of even medium complexity. Hence, it might be easier if the applications are logically 
grouped and visualized separately. 


实际 上 ， 可 视 化 是 使 用 PyGraphviz 创 建 的 。 这 张 图 可 以 变 得 很 大 ， 即 使 面 对 的 时 中 型 的 复杂 
项 目 。 因 此 ， 如 果 应 用 在 逻辑 上 组 织 一 起 ， 而 在 视觉 上 独立 的 ， 那 么 也 能 够 让 人 们 的 理解 轻 
松 些 。 


PyGraphviz Installation and Usage 


If you find the installation of Pyraphvi challenging, then don't worry, you are not 

alone. Recently, | faced numerous issues while installing on Ubuntu, starting from 
Python 3 incompatibility to incomplete documentation. To save your time, | have listed 
the steps that worked for me to reach a working setup. 


On Ubuntu, you will need the following packages installed to install PyGraphviz: 


$ sudo apt-get install python3.4-dev graphviz libgraphviz-dev pkg-config 


Now activate your virtual environment and run pip to install the development version of 
PyGraphviz directly from GitHub, which supports Python 3: 


$ pip install git+http://github.com/pygraphviz/pygraphviz.git#egg=pygraphviz 
Next, install django-extensions and add it to your INSTALLED . APPS. Now, you are all 
set. 


Here is a saple usage to create a raphi dot file for just two apps and to convert it 
to a PNG image for viewing: 


$ python manage.py graph models app1 app2 > models.dot 
$ dot -Tpng models.dot -o models.png 


增 量 变更 还 是 完全 重 写 ? 


Often, you would be handed over legacy code by the application owners in the earnest hope 
that most of it can be used right away or after a couple of minor tweaks. However, reading 
and understanding a huge and often outdated code base is not an easy job. Unsurprisingly, 
most programmers prefer to work on greenfield developent. 


In the best case, the legacy code ought to be easily testable, well documented, and exible 
to work in odern environents so that you can start aking incremental changes in no 

time. In the worst case, you might recommend discarding the existing code and go for a full 
rewrite. Or, as it is commonly decided, the short-term approach would be to keep making 
incremental changes, and a parallel long-term effort might be underway for a complete 
reimplementation. 


A general rule of thumb to follow while taking such decisions is 一 if the cost of rewriting the 
application and maintaining the application is lower than the cost of maintaining the old 
application over time, then it is recommended to go for a rewrite. Care must be taken to 
account for all the factors, such as time taken to get new programmers up to speed, the cost 
of maintaining outdated hardware, and so on. 


Sometimes, the complexity of the application domain becomes a huge barrier against a 
rewrite, since a lot of knowledge learnt in the process of building the older code gets lost. 
Often, this dependency on the legacy code is a sign of poor design in the application like 
failing to externalize the business rules from the application logic. 


The worst form of a rewrite you can probably undertake is a conversion, or a mechanical 
translation from one language to another without taking any advantage of the existing best 
practices. In other words, you lost the opportunity to modernize the code base by removing 
years of cruft. 


Code should be seen as a liability not an asset. As counter-intuitive as it might sound, if you 
can achieve your business goals with a lesser amount of code, you have dramatically 
increased your productivity. Having less code to test, debug, and maintain can not only 
reduce ongoing costs but also make your organization ore agile and exible to change. 


Code is a liability not an asset. Less code is more maintainable. 


Irrespective of whether you are adding features or trimming your code, you must not touch 
your working legacy code without tests in place. 


做 出 任何 的 改变 之 前 都 应 该 做 测试 


In the book Working Effectively with Legacy Code, Michael Feathers defines legacy code as, 
simply, code without tests. He elaborates that with tests one can easily odify the behavior 

of the code quickly and verifiably. In the absence of tests, it is impossible to gauge if the 
change made the code better or worse. 


ften, we do not know enough about legacy code to confidently write a test. Michael 
recommends writing tests that preserve and document the existing behavior, which are 
called characterization tests. 


Unlike the usual approach of writing tests, while writing a characterization test, you will first 
write a failing test with a duy output, say X, because you don't know what to expect. 

When the test harness fails with an error, such as "Expected output X but got Y", then you 
will change your test to expect Y. So, now the test will pass, and it becomes a record of the 
code's existing behavior. 


Note that we might record buggy behavior as well. After all, this is unfamiliar code. 
Nevertheless, writing such tests are necessary before we start changing the code. Later, 
when we know the specifications and code better, we can fix these bugs and update our 
tests (not necessarily in that order). 


写 测试 的 具体 步 又 


Writing tests before changing the code is similar to erecting scaffoldings before the 
restoration of an old building. lt provides a structural framework that helps you confidently 
undertake repairs. 


You ight want to approach this process in a stepwise anner as follows: 


1. Identify the area you need to make changes to. Write characterization tests focusing on 
this area until you have satisfactorily captured its behavior. 


2. Look at the changes you need to ake and write specific test cases for those. Prefer 
smaller unit tests to larger and slower integration tests. 


3. Introduce incremental changes and test in lockstep. If tests break, then try to analyze 
whether it was expected. Don't be afraid to break even the characterization tests if that 
behavior is something that was intended to change. 


If you have a good set of tests around your code, then you can quickly find the effect of 
changing your code. 


换 句 话 来 说 ， 如 果 你 决定 通过 丢掉 自己 的 代码 而 不 是 数据 来 重 写 ， 那么 Django 对 于 此 事 是 颇 
有 帮助 的 。 


日 版 本 的 数据 库 


There is an entire section on legacy databases in Django documentation and rightly so, as 
you will run into them many times. Data is more important than code, and databases are the 
repositories of data in most enterprises. 


You can odernie a legacy application written in other languages or frameworks by 
importing their database structure into Django. As an immediate advantage, you can use the 
Django admin interface to view and change your legacy data. 


Django makes this easy with the inspectdb management command, which looks as follows: 


$ python manage.py inspectdb > models.py 


当 你 的 设置 文件 使 用 旧版 本 的 数据 库 配 置 过 了 ， 这 个 命令 可 以 自动 地 生成 应 用 到 模型 文件 的 
Python 代码 。 


如 果 你 正在 把 该 方法 集成 到 就 旧版 本 数据 库 ， 这 里 给 你 一 些 最 佳 实践 建议 : 


。 预先 了 解 Django ORM 的 限制 。 目 前 ， 多 个 列 ( 合 成) 主键 和 非 关 系 型 数据 库 是 不 支持 
的 。 

e 不 要 要 记 手 动 清理 生成 的 模型 ， 例 如 ， 移 除 Djiango 自 动 创建 的 ID 宛 余 字段 。 

e 外 键 关 系 可 能 必须 手工 定义 。 在 某 些 数据 库 中 自动 生成 的 模型 会 包含 使 用 _id HAHA 
的 整数 字段 。 

。 将 模型 组 织 到 独立 到 应 用 中 。 之 后 ， 在 对 应 到 文件 夹 中 就 可 以 轻松 的 添加 视图 ， 表 单 和 
测试 了 。 

e 记 住 在 昌 版 本 的 数据 库 中 运行 迁移 命令 将 创建 Django 的 管理 表 ( django_* 和 


auth_* ) 9 


理想 的 情况 中 ， 自 动 创建 的 模型 会 立即 运行 起 来 的 ， 不 过 在 实际 情况 中 ， 它 的 运行 带 来 的 是 
很 多 的 尝试 和 错误 。 有 时 候 ，Django 推 断 的 数据 类 型 并 不 合乎 你 的 期 望 。 另 外 的 情况 是 ， 你 
想 要 对 模型 添加 unique_together 这 样 对 元 信息 。 


Eventually, you should be able to see all the data that was locked inside that aging PHP 
application in your familiar Django admin interface. | am sure this will bring a smile to your 
face. 


GK 


In this chapter, we looked at various techniques to understand legacy code. Reading code is 
often an underrated skill. But rather than reinventing the wheel, we need to judiciously reuse 
good working code whenever possible. In this chapter and the rest of the book, we 
emphasize the importance of writing test cases as an integral part of coding. 


本 章 ， 我 们 浏览 了 多 种 技术 以 理解 旧版 本 的 代码 。 阅 读 代码 是 一 个 经 常 被 低估 的 技能 。 不 
过 ， 相 比较 于 重复 发 明 轮 予 ， 我 们 需要 决断 重复 使 用 。 本 书 的 剩 下 章节 ， 我 们 强调 的 是 编写 
测试 案例 作为 代码 完整 性 的 一 部 分 。 

In the next chapter, we will talk about writing test cases and the often frustrating task of 
debugging that follows. 
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第 九 章 测试 与 调试 


本 章 ， 我 们 将 讨论 以 下 话题 : 


e Test-driven development 

e Dos and don'ts of writing tests 
e Mocking 

e Debugging 

e Logging 


每 个 程序 员 都 至 少 考虑 过 跳 过 编写 测试 。 eye 默认 的 app 布 局 拥有 一 个 包含 注释 的 
tests.py 模 块 。 它 也 是 测试 所 需 的 一 个 提示 器 。 不 过 ， 我 们 经 常 希望 跳 过 它 。 


uin 测试 和 写 代 码 很 相似 。 实 际 上 ， 它 就 是 代码 。 因 此 ， 编 写 MO LIE 
写 了 两 次 (或 者 更 多 次 ) 代码 。 有 时 候 ， 我 们 承受 了 太 多 的 压力 ， 当 我 们 花 了 很 多 时 间 党 
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However, eventually, it is pointless to skip tests if you ever want anyone else to use your 
code. Imagine that you invented an electric razor and tried to sell it to your friend saying that 
it worked well for you, but you haven't tested it properly. Being a good friend of yours he or 
she might agree, but imagine the horror if you told this to a stranger. 


为 什么 要 写 测 试 


软件 中 的 测试 是 为 了 检查 软件 本 身 是 否 按 照 人 们 所 期 望 的 那样 正常 运行 。 假 如 不 对 软件 进行 
测试 ， 你 或 许 自 认为 自己 写 的 代码 可 以 正常 运行 ， 不 过 你 也 没有 办 法 证 明 软 件 可 以 正常 运 
行 。 

此 外 ， 重 要 的 是 要 记得 在 Python 中 省 略 掉 单 元 测试 是 比较 危险 的 ， 因 为 Python 存在 自然 一 一 
。 跟 Haskell 这 样 的 语言 不 同 ， 类 型 检查 在 编译 时 并 不 能 够 严格 地 强制 执行 。 单 元 测 
试 在 运行 时 得 到 执行 (虽然 是 独立 执行 ) ， 这 也 是 Python 开发 的 基础 。 


编写 测试 是 你 会 体会 到 什么 是 谦逊 。 测 试 会 指出 你 的 错误 ， 而 且 你 也 得 到 了 一 个 提前 修正 错 
误 到 机 会 。 实 际 上 ， 是 有 一 些 人 愿意 在 编写 代码 之 前 去 写 测试 到 。 


以 测试 驱动 的 开发 


Test-driven development (TDD) is a for of software developent where you first write the 
test, run the test which would fail first, and then write the iniu code needed to make 

the test pass. This might sound counter-intuitive. Why do we need to write tests when we 
know that we have not written any code and we are certain that it will fail because of that? 


However, look again. We do eventually write the code that erely satisfies these tests. This 
eans that these tests are not ordinary tests, they are ore like specifications. They tell you 
what to expect. These tests or specifications will directly coe fro your client's user stories. 
You are writing just enough code to ake it work. 


The process of testdriven developent has any siilarities to the scientific ethod, which 
is the basis of odern science. In the scientific ethod, it is iportant to frae the 
hypothesis first, gather data, and then conduct experients that are repeatable and 
verifiable to prove or disprove your hypothesis. 


My recommendation would be to try TDD once you are comfortable writing tests for your 
projects. Beginners ight find it difficult to frae a test case that checks how the code 
should behave. For the same reasons, | wouldn't suggest TDD for exploratory programming. 


一 个 编写 测试 的 例子 


There are different kinds of tests. However, at the minimum, a programmers need to know 
unit tests since they have to be able to write them. Unit testing checks the smallest testable 
part of an application. Integration testing checks whether these parts work well with each 
other. 


测试 存在 不 同 的 类 型 。 不 过 ， 


The word unit is the key term here. Just test one unit at a time. Let's take a look at a simple 
example of a test case: 


from django.test import TestCase 
from django.core.urlresolvers import resolve 
from .views ue HomeView 
class HomePageOpe E 
def test home page resolves(self): 
view - resolve('/') 
self.assertEqual(view.func. name , 
HomeView.as view(). name ) 


This is a simple test that checks whether, when a user visits the root of our website's 
domain, they are correctly taken to the home page view. Like most good tests, it has a long 
and self-descriptive name. The test simply uses Django's resolve() function to match the 
view callable mapped to the "/" root location to the known view function by their names. 


It is more important to note what is not done in this test. We have not tried to retrieve the 
HTML contents of the page or check its status code. We have restricted ourselves to test 
just one unit, that is, the resolve() function, which maps the URL paths to view functions. 


Assuming that this test resides in, say, app1 of your project, the test can be run with the 
following command: 


$ ./manage.py test appi 
Creating test database for alias 'default'... 


Ran 1 test in 0.088s 
OK 
Destroying test database for alias 'default'... 


This command runs all the tests in the app1 application or package. The default test runner 
will look for tests in all modules in this package matching the pattern test*.py. 


Django now uses the standard unittest module provided by Python rather than bundling its 
own. You can write a testcase class by subclassing from django.test. TestCase. This class 
typically has methods with the following naming convention: 


* test*: Any method whose name starts with test will be executed as a test method. It takes 
no parameters and returns no values. Tests will be run in an alphabetical order. * setUp 
(optional): This method will be run before each test method. It can be used to create 
common objects or perform other initialization tasks that bring your test case to a known 
state. * tearDown (optional): This method will be run after a test method, irrespective of 
whether the test passed or not. Clean-up tasks are usually performed here. 


A test case is a way to logically group test methods, all of which test a scenario. When all the 
test methods pass (that is, do not raise any exception), then the test case is considered 
passed. If any of them fail, then the test case fails. 


断言 方法 


Each test method usually invokes an assert*() method to check some expected outcoe of 
the test. In our first exaple, we used assertEqual() to check whether the function name 
matches with the expected function. 


Similar to assertEqual(), the Python 3 unittest library provides more than 32 assert ethods. 
It is further extended by Django by ore than fraeworkspecific assert ethods. You 

ust choose the ost appropriate ethod based on the end outcome that you are expecting 
so that you will get the most helpful error message. 


Let's see why by looking at an example testcase that has the following setUp() method: 


def setUp(self): 
self.11 = [1, 2] 
self.12 = [1, 0] 


Our test is to assert that 11 and I2 are equal (and it should fail, given their values). Let's take 
a look at several equivalent ways to accomplish this: 


表格 : 略 


The first stateent uses Python's built in assert keyword. Notice that it throws the least 
helpful error. You cannot infer what values or types are in the self.!1 and self.I2 variables. 
This is primarily the reason why we need to use the assert*() methods. 


Next, the exception thrown by assertEqual() very helpfully tells you that you are comparing 
two lists and even tells you at which position they begin to differ. This is exactly similar to the 
exception thrown by the more specialized assertListEqual() function. This is because, as the 
documentation would tell you, if assertEqual() is given two lists for comparison, then it hands 
it over to assertListEqual(). 


Despite this, as the last example proves, it is always better to use the ost specific assert" 
method for your tests. Since the second argument is not a list, the error clearly tells you that 
a list was expected. 


se the ost specific assert" method in your tests. 


Therefore, you need to familiarize yourself with all the assert methods, and choose the ost 
specific one to evaluate the result you expect. This also applies to when you are checking 
whether your application does not do things it is not supposed to do, that is, a negative test 
case. You can check for exceptions or warnings using assertRaises and assertWarns 
respectively. 


编写 更 好 一 些 的 测试 


We have already seen that the best test cases test a small unit of code at a time. They also 
need to be fast. A programmer needs to run tests at least once before every commit to the 
Source control. Even a delay of a few seconds can tempt a programmer to skip running tests 
(which is not a good thing). 


Here are some qualities of a good test case (which is a subjective term, of course) in the 
form of an easy-to-remember mnemonic "F.I.R.S.T. class test case": 


1. Fast: the faster the tests, the more often they are run. Ideally, your tests should 
complete in a few seconds. 

2. Independent: Each test case must be independent of others and can be run in any 
order. 

3. Repeatable: The results must be the same every time a test is run. Ideally, all random 
and varying factors must be controlled or set to known values before a test is run. 

4. Small: Test cases must be as short as possible for speed and ease of understanding. 


5. Transparent: Avoid tricky implementations or ambiguous test cases. 


Additionally, make sure that your tests are automatic. Eliminate any manual steps, no matter 
how small. Automated tests are more likely to be a part of your team's workow and easier 
to use for tooling purposes. 


Perhaps, even more important are the don'ts to remember while writing test cases: 


* Do not (re)test the framework: Django is well tested. Don't check for URL lookup, template 
rendering, and other framework-related functionality. « Do not test implementation details: 
Test the interface and leave the minor implementation details. It makes it easier to refactor 
this later without breaking the tests. * Test models most, templates least: Templates should 
have the least business logic, and they change more often. * Avoid HTML output validation: 
Test views use their context variable's output rather than its HTML-rendered output. * Avoid 
using the web test client in unit tests: Web test clients invoke several components and are 
therefore, better suited for integration tests. e Avoid interacting with external systems: Mock 
them if possible. Database is an exception since test database is in-memory and quite fast. 


Of course, you can (and should) break the rules where you have a good reason to just like 
| did in y first exaple. Itiately, the ore creative you are at writing tests, the earlier 
you can catch bugs, and the better your application will be. 


Mocking 


Most real-life projects have various interdependencies between components. While testing 
one component, the result must not be affected by the behavior of other components. For 
example, your application might call an external web service that might be unreliable in 
terms of network connection or slow to respond. 


Mock objects imitate such dependencies by having the same interface, but they respond to 
method calls with canned responses. After using a mock object in a test, you can assert 
whether a certain method was called and verify that the expected interaction took place. 


Take the exaple of the uperHero profile eligibility test entioned in Pattern: Service 
objects (see Chapter 3, Models). We are going to mock the call to the service object method 
in a test using the Python 3 unittest.mock library: 


from django.test import TestCase 
from unittest.mock import patch 
from django. contribs autune models import User 
class TestSupe WM EU 
def test checl perhero ( Se 
with Rr ‘models. T as ws: 
ws.is_hero.return_value = True 
u = User.objects.create_user(username="t" ) 
r = u.profile.is superhero() 
ws.is_hero.assert_called_with('t') 
self.assertTrue(r) 


Here, we are using patch() as a context manager in a with statement. Since the profile 
odel's is superhero() method will call the SuperHeroWebAPI.is_hero() class method, we 
need to mock it inside the models module. We are also hard-coding the return value of this 
method to be True. 


The last two assertions check whether the method was called with the correct arguments 
and if is hero() returned True, respectively. Since all methods of SuperHeroWebAPI class 
have been mocked, both the assertions will pass. 


Mock objects come from a family called Test Doubles, which includes stubs, fakes, and so 
on. Like movie doubles who stand in for real actors, these test doubles are used in place of 
real objects while testing. While there are no clear lines drawn between them, Mock objects 
are objects that can test the behavior, and stubs are simply placeholder implementations. 


Pattern test fitures and factories 


Problem: Testing a component requires the creation of various prerequisite objects before 
the test. Creating them explicitly in each test method gets repetitive. 


Solution: Utilize factories or fixtures to create the test data objects. 


问题 细节 


Before running each test, Django resets the database to its initial state, as it would be after 
running migrations. Most tests will need the creation of some initial objects to set the state. 
Rather than creating different initial objects for different scenarios, a common set of initial 
objects are usually created. 


This can quickly get unmanageable in a large test suite. The sheer variety of such initial 
objects can be hard to read and later understand. This leads to hardtofind bugs in the 
test data itself! 


Being such a common problem, there are several means to reduce the clutter and write 
clearer test cases. 


解决 方法 细节 


The first solution we will take a look at is what is given in the Django docuentation 
itselftest fixtures. Here, a test fixture is a file that contains a set of data that can be 
iported into your database to bring it to a known state. Typically, they are YML or 
files previously exported from the same database when it had some data. 


For exaple, consider the following test case, which uses a test fixture: 


from django.test import TestCase 


class PostTestCase(TestCase): 
fixtures - ['posts'] 
def setUp(self): 
pass PE 
def test some post f ctionality(self): 
pass I 


Before setUp() gets called in each test case, the specified fixture, posts gets loaded. 
Roughly speaking, the fixture would be searched for in the fixtures directory with certain 
known extensions, for example, app/fixtures/posts.json. 


However, there are a nuber of probles with fixtures. Fixtures are static snapshots of the 
database. They are schema-dependent and have to be changed each time your models 
change. They also might need to be updated when your test-case assertions change. 
pdating a large fixture file anually, with ultiple related objects, is no joke. 


For all these reasons, any consider using fixtures as an antipattern. It is recommended 
that you use factories instead. A factory class creates objects of a particular class that can 
be used in tests. It is a DRY way of creating initial test objects. 


Let's use a model's objects.create method to create a simple factory: 


from django.test import TestCase 
from .models qui Post 


class PostFact 
def make t(self): 
return Post. objects.create(message-"") 
class PostTest e(TestCase): 
def set 人 
self. blank message = ee. makePost() 
def test some post ctiona y(self): 


pass 


opared to using fixtures, the initial object creation and the test cases are all in one place. 
Fixtures load static data as is into the database without calling odeldefined save() 
methods. Since factory objects are dynamically generated, they are more likely to run 
through your application's custom validations. 


However, there is a lot of boilerplate in writing such factory classes yourself. The factory_boy 
package, based on thoughtbot's factory_girl, provides a declarative syntax for creating 
object factories. 


Rewriting the previous code to use factory_boy, we get the following result: 


import factory 
from django.test import TestCase 
from .models import Post 
class PostFactory(factory.Factory): 
class Meta: 
model = Post 
message = "" 
class PostTestCase(TestCase) : 
def setUp(self): 
self.blank message PostFactory.create() 
self.silly message PostFactory.create(message="silly") 
def test_post_title_was_set(self): 
self .assertEqual(self.blank_message.message, 
self.assertEqual(self.silly message.message, "silly") 


Notice how clear the factory class becomes when written in a declarative fashion. The 
attribute's values do not have to be static. You can have sequential, rando, or computed 
attribute values. If you prefer to have more realistic placeholder data such as US addresses, 
then use the django-faker package. 


In conclusion, | would recommend factories, especially factory boy, for most projects that 
need initial test objects. One ight still want to use fixtures for static data, such as lists of 
countries or t-shirt sizes, since they would rarely change. 


Dire Predictions 


After the announcement of the impossible deadline, the entire team seemed to be 
suddenly out of time. They went from 4-week scrum sprints to 1-week sprints. Steve 
wiped every meeting off their calendars except "today's 30-minute catch-up with Steve." 
He preferred to have a one-on-one discussion if he needed to talk to someone at their 
desk. 


At Madam O's insistence, the 30-minute meetings were held at a sound proof hall 20 
levels below the S.H.I.M. headquarters. On Monday, the team stood around a large 
circular table with a gray metallic surface like the rest of the room. Steve stood 
awkwardly in front of it and made a stiff waving gesture with an open palm. 


Django 设计 模式 与 最 佳 实 践 


Even though everyone had seen the holographs come alive before, it never failed to 
amaze them each time. The disc almost segmented itself into hundreds of metallic 
squares and rose like miniature skyscrapers in a futuristic model city. It took them a 
second to realize that they were looking at a 3D bar chart. 


"Our burn-down chart seems to be showing signs of slowing down. | am guessing it is 
the outcome of our recent user tests, which is a good thing. But..." Steve's face seemed 
to show the strain of trying to stie a sneee. He gingerly icked his forefinger 

upwards in the air and the chart smoothly extended to the right. 


"At this rate, projections indicate that we will miss the go-live by several days, at best. | 
did a bit of analysis and found several critical bugs late in our development. We can 
save a lot of time and effort if we can catch them early. | want to put your heads 
together and come up with some i..." 


Steve clasped his mouth and let out a loud sneeze. The holograph interpreted this as a 
sign to zoom into a particularly uninteresting part of the graph. Steve cursed under his 
breath and turned it off. He borrowed a napkin and started noting down everyone's 
suggestions with an ordinary pen. 


One of the suggestions that Steve liked most was a coding checklist listing the most 
common bugs, such as forgetting to apply migrations. He also liked the idea of involving 
users earlier in the development process for feedback. He also noted down some 
unusual ideas, such as a Twitter handle for tweeting the status of the continuous 
integration server. 


At the close of the meeting, Steve noticed that Evan was missing. Where is van? 
he asked. o idea, said Brad looking confused, "he was here a minute ago." 


Learning more about testing 


Django's default test runner has improved a lot over the years. However, test runners 
such as py.test and nose are still superior in terms of functionality. They make your 
tests easier to write and run. Even better, they are compatible with your existing test 
cases. 


You ight also be interested in knowing what percentage of your code is covered by tests. 
This is called Code coverage and coverage.py is a very popular tool for finding this out. 


Most projects today tend to use a lot of JavaScript functionality. Writing tests for them 
usually require a browser-like environment for execution. Selenium is a great browser 
automation tool for executing such tests. 
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While a detailed treatment of testing in Django is outside the scope of this book, | would 
strongly recommend that you learn more about it. 


If nothing else, the two main takeaways | wanted to convey through this section are first, 
write tests, and second, once you are confident at writing the, practice TDD. 


Debugging 


Despite the most rigorous testing, the sad reality is, we still have to deal with bugs. Django 
tries its best to be as helpful as possible while reporting an error to help you in debugging. 
However, it takes a lot of skill to identify the root cause of the problem. 


Thankfully, with the right set of tools and techniques, we can not only identify the bugs but 
also gain great insight into the runtime behavior of your code. Let's take a look at some of 
these tools. 


Django 的 调试 页 面 


If you have encountered any exception in development, that is, when DEBUG=True, then 
you would have already seen an error page similar to the following screenshot: 


图 片 : % 


Since it comes up so frequently, most developers tend to miss the wealth of information in 
this page. Here are some places to take a look at: 


。 Exception details: Obviously, you need to read what the exception tells you very carefu 
。 Exception location: This is where Python thinks where the error has occurred. In Django 
* Traceback: This was the call stack when the error occurred. The line that caused the er 
* Request information: This is a table (not shown in the screenshot) that shows context v 


" - 


更 友好 的 测试 页 面 


Often, you may wish for more interactivity in the default Django error page. The django- 





extensions package ships with the fantastic Werkzeug debugger that provides exactly this 
feature. In the following screenshot of the same exception, notice a fully interactive Python 
interpreter available at each level of the call stack: 


图 片 : % 


To enable this, in addition to adding django extensions to your INSTALLED APPS, you will 
need to run your test server as follows: 


$ python manage.py runserver_plus 


Despite the reduced debugging inforation, | find the Werkeug debugger to be more useful 
than the default error page. 


print x 


Sprinkling print() functions all over the code for debugging might sound primitive, but it has 
been the preferred technique for many programmers. 


Typically, the print() functions are added before the line where the exception has occurred. It 
can be used to print the state of variables in various lines leading to the exception. You can 
trace the execution path by printing soething when a certain line is reached. 


In development, the print output usually appears in the console window where the test 
server is running. Whereas in production, these print outputs might end up in your server log 
file where they would add a runtie overhead. 


In any case, it is not a good debugging technique to use in production. Even if you do, the 
print functions that are added for debugging should be removed from being committed to 
your source control. 


日 志 


The ain reason for including the previous section was to sayYou should replace the 

print() functions with calls to logging functions in Python's logging module. Logging has 
several advantages over printing: it has a timestamp, a clearly marked level of urgency (for 
example, INFO, DEBUG), and you don't have to remove them from your code later. 


Logging is fundamental to professional web development. Several applications in your 
production stack, like web servers and databases, already use logs. Debugging might take 
you to all these logs to retrace the events that lead to a bug. It is only appropriate that your 
application follows the same best practice and adopts logging for errors, warnings, and 
informational messages. 


Unlike the common perception, using a logger does not involve too much work. Sure, the 
setup is slightly involved but it is merely a one-time effort for your entire project. Even more, 
most project templates (for example, the edge template) already do this for you. 


nce you have configured the LOGGING variable in settings.py, adding a logger to your 
existing code is quite easy, as shown here: 


import logging 
logger = logging.getLogger(__name__ ) 
def complicatec ev : 
logger.debug("Entered the complicated view()!") 


The logging module provides various levels of logged messages so that you can easily filter 
out less urgent essages. The log output can be also formatted in various ways and routed 
to any places, such as standard output or log files. Read the documentation of Python's 
logging module to learn more. 


Django 人 调试 工具 


The Django Debug Toolbar is an indispensable tool not just for debugging but also for 
tracking detailed information about each request and response. Rather than appearing only 
during exceptions, the toolbar is always present in your rendered page. 


Initially, it appears as a clickable graphic on the right-hand side of your browser window. On 
clicking, a toolbar appears as a dark semi-transparent sidebar with several headers: 


图 片 : 略 


ach header is filled with detailed inforation about the page fro the nuber of SQL 

queries executed to the templates that we use to render the page. Since the toolbar 
disappears when DEBUG is set to False, it is pretty much restricted to being a development 
tool. 


The Python debugger pdb While debugging, you might need to stop a Django application in 
the middle of execution to examine its state. A simple way to achieve this is to raise an 
exception with a simple assert False line in the required place. What if you wanted to 
continue the execution step by step fro that line? This is possible with the use of an 
interactive debugger such as Python's pdb. Simply insert the following line wherever you 
want the execution to stop and switch to pdb: 


import pdb; pdb.set_trace() 


Once you enter pdb, you will see a command-line interface in your console window with a 
(Pdb) prompt. At the same time, your browser window will not display anything as the 
request has not finished processing. 


The pdb command-line interface is extremely powerful. It allows you to go through the code 
line by line, examine the variables by printing them, or execute arbitrary code that can even 
change the running state. The interface is quite similar to GDB, the GNU debugger. 


其 他 的 调试 器 


There are several drop-in replacements for pdb. They usually have a better interface. Some 
of the console-based debuggers are as follows: 


* ipdb: Like IPython, this has autocomplete, syntax-colored code, and so on. * pudb: Like old 
Turbo C IDEs, this shows the code and variables side by side. * IPython: This is not a 
debugger. You can get a full IPython shell anywhere in your code by adding the from IPython 
import embed; embed()line. 


PuDB is my preferred replacement for pdb. It is so intuitive that even beginners can easily 
use this interface. Like pdb, just insert the following code to break the execution of the 
program: 


import pudb; pudb.set trace() 


When this line is executed, a full-screen debugger is launched, as shown here: 
图 片 : 略 
Press the ? key to get help on the complete list of keys that you can use. 


此 外 ， 还 存在 多 种 图 形 化 的 调试 器 ， 有些 是 独立 使 用 的 ， 比 如 winpdb 和 其 他 的 集成 到 IDE 中 的 
调试 器 ， 比 如 PyCharm,PyDev, 和 Komodo。 我 们 会 推荐 你 多 去 尝试 几 个 调试 器 ， 直 道 你 发 现 
那个 适合 你 的 工具 。 


T4 iX Django7€ 4x 


需要 在 settings.py 中 设置 TEMPLATE_DEBUG 为 True， 这 样 Django 就 可 以 更 好 在 模板 中 出 
现 错误 时 显示 错误 页 面 。 


有 多 种 简陋 的 方法 来 调试 模板 ， 比 如 插入 想 要 的 变量 ，， 或 者 是 你 想 要 像 这 样 使 用 内 建 的 调 
试 标签 ， 拉 取 所 有 的 变量 (在 一 个 很 方便 的 ， 可 点 击 的 文本 区 域内 部 ) 


«textarea onclick="this.focus();this.select()" style="width: 100%;"> 
{% filter force_escape %} 
{% debug %} 
{% endfilter %} 
</textarea> 


更 好 的 选择 是 使 用 之 前 提 到 的 Django 调 试 工具 。 它 不 仅 能 够 告诉 你 上 下 文 变量 中 的 值 ， 而 且 
还 显示 了 模板 中 的 继承 树 。 


不 过 ， 你 要 是 想 要 在 模板 中 部 暂停 以 检查 状态 ( 即 ， 在 循环 内 部 ) ， 调 试 将 会 是 此 类 情况 的 
最 佳 选 择 。 实 际 上 ， 你 可 以 使 用 之 前 提 到 Python 解释 器 中 的 任何 一 个 来 为 你 的 模板 使 用 自 定 
义 模 板 标签 。 


下 面 是 一 个 此 类 模板 标签 的 简单 实现 。 在 模板 标签 的 包 目 录 内 创建 以 下 文件 : 


# templatetags/debug.py 
import pudb as dbg # Change to any *db 
from django.template import Library, Node 
register = Library() 
class PdbNode(Node): 
def render(self, context): 
dbg.set trace() 
return '' 
Qregister.tag 
def pdb(parser, token): 
# Debugger will stop here 
return PdbNode() 


在 模板 中 ， 载 入 模板 标 签 库 ， 在 需要 执行 暂停 的 地 方 插入 pdg 标 签 ， 以 及 输入 调试 器 : 


{% load debug %} 
{% for item in items %} 
{# Some place you want to break #} 
{% pdb %} 
{% endfor %} 


在 调试 器 内 部 ， 你 可 以 验证 任何 事情 ， 使 用 上 下 文字 典 引 入 上 下 文 变量 


>>> print(context["item"]) 
Itemo 


如 果 你 需要 在 调试 和 内 省 上 使 用 更 多 的 模板 标签 ， 那 么 我 会 推荐 你 试验 
平 django-template-debug 包 。 
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这 一 章 ， 我 们 浏览 了 Django 中 执行 测试 的 背后 动机 和 概念 。 我 们 也 发 现 了 在 编写 测试 时 所 遵 
循 的 多 种 最 佳 实践 。 


在 调试 的 小 节 ， 我 们 熟悉 了 使 用 多 种 调试 工具 和 技术 发 现在 Django 代 码 和 模板 的 问题 。 


在 下 一 章 ， 我 们 会 通过 理解 多 种 安全 问题 ， 以 及 如 何 减少 来 自 各 种 恶意 攻击 的 威胁 ， 来 更 进 
一 步 靠近 生产 环境 中 的 代码 o 
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第 十 章 安全 
这 一 章 ， 我 们 谈 及 以 下 议题 : 


x 
。 各 种 web 攻 击 及 其 对 策 
e Django 对 于 安全 问题 的 能 与 不 能 
e 对 Django 应 用 的 安全 检查 


跨 站 脚本 (XSS) 


为 什么 cookie 值 得 如 此 关注 


In this chapter, we will discuss the following topics: 
在 这 一 章 ， 我 们 将 讨论 以 下 话题 : 

。Picking a web stack 挑选 一 个 web 服 务 

。Hosting approaches 托管 方法 

。Deployment tools 发 布 工具 

e Monitoring 监控 

* Performance tips 性 能 建议 


So, you have developed and tested a fully functional web application in Django. Deploying 
this application can involve a diverse set of activities from choosing your hosting provider to 
performing installations. Even more challenging could be the tasks of maintaining a 
production site working without interruptions and handling unexpected bursts in traffic. 


你 已 经 使 用 Django 开 发 并 测试 了 完整 功能 的 web 应 用 。 而 部 署 这 个 应 用 就 涉及 到 了 选择 你 的 
主机 托管 服务 商 执行 安装 的 一 组 各 种 不 同 的 行为 。 甚 至 是 更 具 挑 战 的 维护 生产 环境 中 正在 使 
用 的 网 站 ， 而 不 用 中 断 它 ， 并 处 理 未 被 预料 到 到 突 发 流量 。 


The discipline of system administration is vast. Hence, this chapter will cover a lot of ground. 
However, given the limited space, we will attempt to familiarize you with the various aspects 
of building a production environment. 


系统 管理 员 的 规定 是 很 多 的 9 因此 ’ KREBEYA RILA ó 篇 幅 虽 然 所 限 但 是 我 们 会 试 
着 让 你 尽 可 能 多 的 熟悉 构建 生成 环境 的 方方面面 。 


生成 环境 


Although, most of us intuitively understand what a production environment is, it is worthwhile 
to clarify what it really means. A production environment is simply one where end users use 
your application. It should be available, resilient, secure, responsive, and must have 
abundant capacity for current (and future) needs. 
尽管 ， 我 们 都 大 多 数 的 人 从 直觉 上 都 能 够 理解 生产 环境 是 个 什么 东西 ， 但 是 在 这 里 ， 值 得 我 
们 花 点 时 间 来 漆 清 生产 环境 的 丨 正 的 意思 。 生 产 环 境 是 一 个 多 简单 的 终端 用 户 可 以 使 用 你 所 
开发 的 应 用 的 地 方 。 它 应 该 是 可 用 的 、 可 还 原 的、 安全 的 、 灵 活 响 应 的 、 而 且 必 须 拥 有 当前 
(和 未 来 ) 充足 的 扩展 能 力 。 


Unlike a development environment, the chance of real business damage due to any issues 
in a production environment is high. Hence, before moving to production, the code is moved 
to various testing and acceptance environments in order to get rid of as many bugs as 
possible. For easy traceability, every change made to the production environment must be 
tracked, documented, and made accessible to everyone in the team. 


不 同 于 开发 环境 ， 在 生产 环境 中 对 现实 业务 的 破坏 所 引发 的 任何 问题 都 可 能 要 付出 非常 高 郊 
都 代价 。 因 此 ， 在 迁移 到 生产 环境 中 之 前 ， 代 码 应 该 接受 多 种 测试 ， 和 认可 的 环境 中 以 尽 可 
能 多 多 去 除 bug。 简单 来 说 ， 每 个 应 用 到 生产 环境 中 的 变更 都 必须 追踪 、 纪 录 、 而 且 要 然 团队 
中 任何 人 都 能 够 理解 。 


As an upshot, there must be no development performed directly on the production 
environment. In fact, there is no need to install development tools, such as a compiler or 
debugger in production. The presence of any additional software increases the attack 
surface of your site and could pose a security risk. 


Most web applications are deployed on sites with extremely low downtime, say, large data 
centers running 24/7/365. By designing for failure, even if an internal component fails, there 
is enough redundancy to prevent the entire system crashing. This concept of avoiding a 
single point of failure (SPOF) can be applied at every level—hardware or software. 


Hence, it is crucial which collection of software you choose to run in your production 
environment. 


选择 Web 服 务 


So far, we have not discussed the stack on which your application will be running on. Even 
though we are talking about it at the very end, it is best not to postpone such decisions to the 
later stages of the application lifecycle. Ideally, your development environment must be as 
close as possible to the production environment to avoid the "but it works on my machine" 
argument. 


By a web stack, we refer to the set of technologies that are used to build a web application. 
It is usually depicted as a series of components, such as OS, database, and web server, all 
piled on top of one another. Hence, it is referred to as a stack. 


We will mainly focus on open source solutions here because they are widely used. However, 
various commercial applications can also be used if they are more suited to your needs. 


栈 的 组 件 


A production Django web stack is built using several kinds of application (or layers, 
depending on your terminology). While constructing your web stack, some of the choices 
you might need to make are as follows: 


生产 环境 中 的 Django web 栈 使 用 的 是 多 种 应 用 (或 者 层 ， 视 使 用 的 术语 不 同 而 不 同 ) 。 当 构 
建 Web 栈 时 ， 如 下 是 你 可 能 遇 到 当选 择 : 


e Which and distribution? For exaple Debian, Red Hat, or penBD. 
e Which WI server? For exaple unicorn, uWl. 


e Which web server? For exaple pache, ginx. 

e Which database? For exaple PostgreL, MyL, or Redis. 

e Which caching syste? For exaple Mecached, Redis. 

e Which process control and onitoring syste? For exaple pstart, Systemd, or 
Supervisord. 

e How to store static edia? For exaple aon , loudFront. 


There could be several more, and these choices are not mutually exclusive either. Some use 
several of these applications in tandem. For example, username availability might be looked 
up on Redis, while the primary database might be PostgreSQL. 


There is no 'one sie fits all' answer when it coes to selecting your stack. Different 
components have different strengths and weaknesses. Choose them only after careful 
consideration and testing. For instance, you might have heard that Nginx is a popular choice 
for a web server, but you might actually need Apache's rich ecosystem of modules or 
options. 


Sometimes, the selection of the stack is based on various non-technical reasons. Your 
organiation ight have standardied on a particular operating syste, say, Debian for all 
its servers. Or your cloud hosting provider might support only a limited set of stacks. 


Hence, how you choose to host your Django application is one of the key factors in 
determining your production setup. 


托管 


When it comes to hosting, you need to make sure whether to go for a hosting platform such 
as Heroku or not. If you do not know much about managing a server or do not have anyone 
with that knowledge in your team, then a hosting platform is a convenient option. 


平台 即 服务 


Platform as a service A Platform as a ervice Paa is defined as a cloud service where 
the solution stack is already provided and managed for you. Popular platforms for Django 
hosting include Heroku, PythonAnywhere, and Google App Engine. 


In most cases, deploying a Django application should be as simple as selecting the services 
or coponents of your stack and pushing out your source code. You do not have to perform 
any system administration or setup yourself. The platform is entirely managed. 


Like most cloud services, the infrastructure can also scale on demand. If you need an 
additional database server or more RAM on a server, it can be easily provisioned from a web 
interface or the command line. The pricing is primarily based on your usage. 


The bottom line with such hosting platforms is that they are very easy to set up and ideal for 
smaller projects. They tend to be more expensive as your user base grows. 


Another downside is that your application might get tied to a platform or becoe difficult to 
port. For instance, oogle pp ngine is used to support only a non-relational database, 
which means you need to use django-nonrel, a fork of Django. This limitation is now 
somewhat mitigated with Google Cloud SQL. 
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虚拟 私有 服务 器 


A virtual private server (VPS) is a virtual machine hosted in a shared environment. From the 
developer's perspective, it would seem like a dedicated machine (hence, the word private 
preloaded with an operating syste. You will need to install and set up the entire stack 
yourself, though many VPS providers such as WebFaction and DigitalOcean offer easier 
Django setups. 


If you are a beginner and can spare some time, | highly recommend this approach. You 
would be given root access, and you can build the entire stack yourself. You will not only 
understand how various pieces of the stack come together but also have full control in 
finetuning each individual coponent. 


Compared to a PaaS, a VPS might work out to be more value for money, especially for 
hightraffic sites. You ight be able to run several sites fro the same server as well. 


另外 托管 主机 的 方法 


Other hosting approaches Even though hosting on a platform or VPS are by far the two most 
popular hosting options, there are plenty of other options. If you are interested in maximizing 
performance, you can opt for a bare metal server with colocation from providers, such as 
Rackspace. 


On the lighter end of the hosting spectrum, you can save the cost by hosting multiple 
applications within Docker containers. Docker is a tool to package your application and 
dependencies in a virtual container. Compared to traditional virtual machines, a Docker 
container starts up faster and has minimal overheads (since there is no bundled operating 
system or hypervisor). 


Docker is ideal for hosting micro services-based applications. It is becoming as ubiquitous 
as virtualization with almost every PaaS and VPS provider supporting them. It is also a great 
development platform since Docker containers encapsulate the entire application state and 
can be directly deployed to production. 


开发 工具 


Once you have zeroed in on your hosting solution, there could be several steps in your 
deployment process, from running regression tests to spawning background services. 


The key to a successful deployment process is automation. Since deploying applications 
involve a series of welldefined steps, it can be rightly approached as a programming 
problem. Once you have an automated deployment in place, you do not have to worry about 
deployments for fear of missing a step. 


In fact, deployments should be painless and as frequent as required. For example, the 
Facebook team can release code to production up to twice a day. Considering Facebook's 
enormous user base and code base, this is an impressive feat, yet, it becoes necessary as 
eergency bug fixes and patches need to be deployed as soon as possible. 


A good deployment process is also idempotent. In other words, even if you accidentally run 
the deployment tool twice, the actions should not be executed twice (or rather it should leave 
itin the same state). 


Let's take a look at some of the popular tools for deploying Django applications. 


Fabric 


Fabric is favored among Python web developers for its simplicity and ease of use. It expects 
a file naed fabfile.py that defines all the actions for deployent or otherwise) in your 

project. Each of these actions can be a local or remote shell command. The remote host is 
connected via SSH. 


The key strength of Fabric is its ability to run commands on a set of remote hosts. For 
instance, you can define a web group that contains the hostnames of all web servers in 
production. You can run a Fabric action only against these web servers by specifying the 
web group name on the command line. 


To illustrate the tasks involved in deploying a site using Fabric, let's take a look at a typical 
deployment scenario. 


典型 的 部 署 步 又 


Imagine that you have a medium-sized web application deployed on a single web server. Git 
has been chosen as the version control and collaboration tool. A central repository that is 
shared with all users has been created in the form of a bare Git tree. 


Let's assume that your production server has been fully set up. When you run your Fabric 
deployment command, say, fab deploy, the following scripted sequence of actions take 
place: 


Run all tests locally. 

Commit all local changes to Git. 

Push to a remote central Git repository. 

Resolve erge conicts, if any. 

ollect the static files , iages. 

opy the static files to the static file server. 

At remote host, pull changes from a central Git repository. 
At remote host, run (database) migrations. 
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At remote host, touch app.wsgi to restart WSGI server. 


The entire process is automatic and should be completed in a few seconds. By default, if 
any step fails, then the deployment gets aborted. Though not explicitly mentioned, there 
would be checks to ensure that the process is idempotent. 


Note that Fabric is not yet compatible with Python 3, though the developers are in the 
process of porting it. In the meantime, you can run Fabric in a Python 2.x virtual environment 
or check out similar tools, such as Pylnvoke. 


Managing multiple servers in different states can be hard with Fabric. onfiguration 
management tools such as Chef, Puppet, or Ansible try to bring a server to a certain desired 
state. 


nlike Fabric, which requires the deployent process to be specified in an iperative 
anner, these configurationanageent tools are declarative. You just need to define the 
final state you want the server to be in, and it will figure out how to get there. 


For example, if you want to ensure that the Nginx service is running at startup on all your 
web servers, then you need to define a server state having the ginx service both running 
and starting on boot. On the other hand, with Fabric, you need to specify the exact steps to 
install and configure ginx to reach such a state. 


ne of the ost iportant advantages of configurationanageent tools is that they are 

idepotent by default. Your servers can go fro an unknown state to a known state， 

resulting in easier server configuration anageent and reliable deployent. ong 
configurationanageent tools, hef and Puppet enjoy wide popularity since they were 

one of the earliest tools in this category. However, their roots in Ruby can make them look a 
bit unfamiliar to the Python programmer. For such folks, we have Salt and Ansible as 
excellent alternatives. 


onfigurationanageent tools have a considerable learning curve copared to simpler 
tools, such as Fabric. However, they are essential tools for creating reliable production 
environments and are certainly worth learning. 
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Even a medium-sized website can be extremely complex. Django might be one of the 
hundreds of applications and services running and interacting with each other. In the same 
way that the heart beat and other vital signs can be constantly monitored to assess the 
health of the human body, so are various metrics collected, analyzed, and presented in most 
production systems. 


While logging keeps track of various events, such as arrival of a web request or an 
exception, monitoring usually refers to collecting key information periodically, such as 
memory utilization or network latency. However, differences get blurred at application level, 
such as, while monitoring database query performance, which might very well be collected 
from logs. 


Monitoring also helps with the early detection of problems. Unusual patterns, such as spikes 
or a gradually increasing load, can be signs of bigger underlying problems, such as a 
memory leak. A good monitoring system can alert site owners of problems before they 
happen. Monitoring tools usually need a backend service (sometimes called agents) to 
collect the statistics, and a frontend service to display dashboards or generate reports. 
Popular data collection backends include StatsD and Monit. This data can be passed to 
frontend tools, such as Graphite. 


There are several hosted monitoring tools, such as New Relic and Status.io, which are 
easier to set up and use. 


Measuring performance is another important role of monitoring. As we will soon see, any 
proposed optimization must be carefully measured and monitored before getting 
implemented. 


性 能 


Performance is a feature. Studies show how slow sites have an adverse effect on users, and 
therefore, revenue. For instance, tests at Amazon in 2007 revealed that for every 100 ms 
increase in load time of amazon.com, the sales decreased by 1 percent. 


Reassuringly, several high-performance web applications such as Disqus and Instagram 
have been built on Django. At Disqus, in 2013, they could handle 1.5 million concurrently 
connected users, 45,000 new connections per second, 165,000 messages/second, with less 
than 0.2 seconds latency end-to-end. 


The key to iproving perforance is finding where the bottlenecks are. Rather than relying 
on guesswork, it is always recoended that you easure and profile your application to 
identify these performance bottlenecks. As Lord Kelvin would say: 


If you can't measure it, you can't improve it. 


In most web applications, the bottlenecks are likely to be at the browser or the database end 
rather than within Django. However, to the user, the entire application needs to be 
responsive. 


Let's take a look at some of the ways to improve the performance of a Django application. 
Due to widely differing techniques, the tips are split into two parts: frontend and backend. 


前 端 性 能 


Django programmers might quickly overlook frontend performance because it deals with 
understanding how the client-side, usually a browser, works. However, to quote Steve 
Souders' study of Alexa-ranked top 10 websites: 


80-90% of the end-user response time is spent on the frontend. Start there. 


A good starting point for frontend optimization would be to check your site with oogle Page 
peed or Yahoo Ylow coonly used as browser plugins. These tools will rate your 

site and recommend various best practices, such as minimizing the number of HTTP 
requests or gzipping the content. 


As a best practice, your static assets, such as images, style sheets, and JavaScript files 
ust not be served through Django. Rather a static file server, cloud storages such as 
Amazon S3 or a content delivery network (CDN) should serve them for better performance. 


Even then, Django can help you improve frontend performance in a number of ways: 


* Cache infinitely with CachedStaticFilesStorage: The fastest way to load static assets i 
CachedStaticFilesStorage solves this elegantly by appending the asset's MD5 hash to its f 


To use this, set the STATICFILES STORAGE to CachedStaticFilesStorage or, if you have a cu 


* Use a static asset manager: An asset manager can preprocess your static assets to minif 
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后 端 性 能 


The scope of backend performance improvements covers your entire server-side web stack, 
including database queries, template rendering, caching, and background jobs. You will want 
to extract the highest perforance fro the, since it is entirely within your control. 


For quick and easy profiling needs, django-debug-toolbar is quite handy. We can also use 
Python profiling tools, such as the hotshot module for detailed analysis. In Django, you can 
use one of the several profiling iddleware snippets to display the output of hotshot in the 
browser. 


recent liveprofiling solution is django-silk. It stores all the requests and responses in the 
configured database, allowing aggregated analysis over an entire user session, say, to find 
the worstperforing views. It can also profile any piece of Python code by adding a 
decorator. 


As before, we will take a look at some of the ways to improve backend performance. 
However, considering they are vast topics in themselves, they have been grouped into 
sections. Many of these have already been covered in the previous chapters but have been 
summarized here for easy reference. 


模板 


As the documentation suggests, you should enable the cached template loader in 
production. This avoids the overhead of reparsing and recompiling the templates each tie it 
needs to be rendered. The cached teplate is copiled the first tie it is needed and then 
stored in memory. Subsequent requests for the same template are served from memory. 


If you find that another teplating language such as inja renders your page significantly 
faster, then it is quite easy to replace the builtin Django teplate language. There are 
several libraries that can integrate Django and Jinja2, such as django-jinja. Django 1.8 is 
expected to support multiple templating engines out of the box. 


数据 库 


Sometimes, the Django RM can generate inefficient L code. There are several 


optimization patterns to improve this: 


Reduce database hits with select_related: If you are using a OneToOneField or a Foreign 
Reduce database hits with prefetch_related: For accessing a ManyToManyField method or, 

Fetch only needed fields with values or values_list You can save tie and memory usage b 
Denormalize models: Selective denormalization improves performance by reducing joins at 


Add an Index: If a non-primary key gets searched a lot in your queries, consider settin 


* Create, update, and delete multiple rows at once: Multiple objects can be operated upon 
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As a last resort, you can always finetune the raw L stateents using proven database 
performance expertise. However, maintaining the SQL code can be painful over time. 


缓存 


Any computation that takes time can take advantage of caching and return precomputed 
results faster. However, the problem is stale data or, often, quoted as one of the hardest 
things in computer science, cache invalidation. This is coonly spotted when, despite 
refreshing the page, a YouTube video's view count doesn't change. 


Django has a exible cache system that allows you to cache anything from a template 
fragment to an entire site. It allows a variety of pluggable backends such as filebased or 
databased backed storage. 


Most production systems use a memory-based caching system such as Redis or 
Memcached. This is purely because volatile memory is many orders of magnitude faster 
than disk-based storage. 


Such cache stores are ideal for storing frequently used but ephemeral data, like user 
sessions. 


2% B session & 3% 


By default, Django stores its user session in the database. This usually gets retrieved for 
every request. To improve performance, the session data can be stored in memory by 
changing the SESSION_ENGINE setting. For instance, add the following in settings.py to 
store the session data in your cache: 


SESSION_ENGINE = "django.contrib.sessions.backends.cache" 





Since some cache storages can evict stale data leading to the loss of session data, it is 
preferable to use Redis or Memcached as the session store, with memory limits high enough 
to support the maximum number of active user sessions. 


缓存 框架 


For basic caching strategies, it might be easier to use a caching framework. Two popular 
ones are django-cache-machine and django-cachalot. They can handle common scenarios, 
such as automatically caching results of queries to avoid database hits every time you 
perform a read. 


就 基本 的 缓存 策略 来 说 ， 


The simplest of these is Django-cachalot, a successor of Johnny Cache. It requires very little 
configuration. It is ideal for sites that have multiple reads and infrequent writes (that is, the 
vast majority of applications), it caches all Django ORM read queries in a consistent manner. 


缓存 模式 


nce your site starts getting heavy traffic, you will need to start exploring several caching 
strategies throughout your stack. Using Varnish, a caching server that sits between your 
users and Django, many of your requests might not even hit the Django server. 


Varnish can make pages load extremely fast (sometimes, hundreds of times faster than 
normal). However, if used improperly, it might serve static pages to your users. arnish can 
be easily configured to recognie dynaic pages or dynaic parts of a page such as a 
shopping cart. 


Russian doll caching, popular in the Rails community, is an interesting template cache- 
invalidation pattern. Imagine a user's timeline page with a series of posts each containing a 
nested list of comments. In fact, the entire page can be considered as several nested lists of 
content. At each level, the rendered template fragment gets cached. 


So, if anew comment gets added to a post, only the associated post and timeline caches 
get invalidated. otice that we first invalidate the cache content directly outside the changed 
content and move progressively until at the outermost content. The dependencies between 
models need to be tracked for this pattern to work. 


Another common caching pattern is to cache forever. Even after the content changes, the 
user might get served stale data from the cache. However, an asynchronous job, such as, a 
elery job, also gets triggered to update the cache. You can also periodically warm the 
cache at a certain interval to refresh the content. ssentially, a successful caching strategy 
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identifies the static and dynaic parts of a site. For any sites, the dynaic parts are the 
userspecific data when you are logged in. If this is separated from the generally available 
public content, then implementing caching becomes easier. 


Don't treat caching as integral to the working of your site. The site must fall back to a slower 
but working state even if the caching system breaks down. 


注释 


Cranos It was six in the morning and the S.H.I.M. building was surrounded by a grey 
fog. Somewhere inside, a small conference room had been designated the "War 
Room." For the last three hours, the SuperBook team had been holed up here diligently 
executing their pre-go-live plan. 


More than 30 users had logged on the IRC chat room #superbookgolive from various 
parts of the world. The chat log was projected on a giant whiteboard. When the last 
item was struck off, Evan glanced at Steve. Then, he pressed a key triggering the 
deployment process. 


The room fell silent as the script output kept scrolling off the wall. One error, Steve 
thought—just one error can potentially set them back by hours. Several seconds later, 
the command prompt reappeared. It was live! The team erupted in joy. Leaping from 
their chairs they gave highfives to each other. oe were crying tears of happiness. 

fter weeks of uncertainty and hard work, it all seemed surreal. 


However, the celebrations were short-lived. A loud explosion from above shook the 
entire building. Steve knew the second breach had begun. He shouted to Evan, "Don't 
turn on the beacon until you get my message," and sprinted out of the room. 


As Steve hurried up the stairway to the rooftop, he heard the sound of footsteps above hi. 

It was Mada . he opened the door and ung herself in. He could hear her screaming 

"No!" and a deafening blast shortly after that. By the time he reached the rooftop, he saw 
Madam O sitting with her back against the wall. She clutched her left arm and was wincing in 
pain. Steve slowly peered around the wall. At a distance, a tall bald man seemed to be 
working on something with the help of two robots. 


Django 设计 模式 与 最 佳 实践 


"He looks like...." Steve broke off, unsure of himself. Yes, it is Hart. Rather | should 

say he is ranos now. What? Yes, a split personality. onster that laid hidden in 

Hart's ind for years. | tried to help him control it. Many years back, | thought | had 
stopped it from ever coming back. However, all this stress took a toll on him. Poor thing, 
if only | could get near him." 


Poor thing indeed—he nearly tried to kill her. Steve took out his mobile and sent out a 
message to turn on the beacon. He had to improvise. With his hands high in the air and 
fingers crossed, he stepped out. The two robots immediately aimed directly at him. 
Cranos motioned them to stop. Well, who do we have here? Mr. uperBook hiself. 

Did | crash into your launch party, teve? 


"It was our launch, Hart." 


"Don't call me that," growled Cranos. "That guy was a fool. He wrote the Sentinel code 
but he never understood its potential. | mean, just look at what Sentinels can do— 
unravel every cryptographic algorithm known to an. What happens when it enters an 
intergalactic network? 


The hint was not lost on teve. uperBook? he asked slowly. 


Cranos let out a malicious grin. Behind him, the robots were busy wiring into S.H.I.M.'s 
core network. "While your SuperBook users will be busy playing SuperVille, the 
tentacles of Sentinel will spread into new unsuspecting worlds. Critical systems of every 
intelligent species will be sabotaged. The Supers will have to bow to a new intergalactic 
supervillain—Cranos." As Cranos was delivering this extended monologue, Steve 
noticed a movement in the corner of his eyes. It was Acorn, the super-intelligent 
squirrel, scurrying along the right edge of the rooftop. He also spotted Hexa hovering 
strategically on the other side. He nodded at them. 


Hexa levitated a garbage bin and ung it towards the robots. corn distracted them 
with high-pitched whistles. "Kill them all!" Cranos said irritably. s he turned to watch 
his intruders, teve fished out his phone, dialed into FaceTime and held it towards 
Cranos. 


"Say hello to your old friend, Cranos," said Steve. Cranos turned to face the phone and 
the screen revealed Madam O's face. With a smile, she muttered under her breath, 
"Taradiddle Bumfuzzle!" The expression on Cranos' face changed instantly. The 
seething anger disappeared. He now looked like a man they had once known. 


>What happened? asked Hart confused. 
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"We thought we had lost you," said Madam O over the phone. "| had to use hypnotic 
trigger words to bring you back." Hart took a moment to survey the scene around him. 


Then, he slowly smiled and nodded at her. 


One Year Later 


Who would have guessed Acorn would turn into an intergalactic singing sensation in 
less than a year? His latest albu corn Unplugged" debuted at the top of Billboard's 

Top 20 chart. He had thrown a grand party in his new white mansion overlooking a lake. 
The guest list included superheroes, pop stars, actors, and celebrities of all sorts. 


"So, there was a singer in you after all," said Captain Obvious holding a martini. 


"| guess there was," replied Acorn. He looked dazzling in a golden tuxedo with all sorts 


of bling-bling. 


>teve appeared with Hexa in towwho looked ravishing in a owing silver gown. "Hey 
Steve, Hexa.... It has been a while. Is SuperBook still keeping you late at work, teve? 


"Not so much these days. Knock on wood," replied Hexa with a smile. 


>h, you guys did a fantastic job. | owe a lot to uperBook. My first single, Warning: 
Contains Nuts', was a huge hit in the Tucana galaxy. They watched the video on SuperBook 
more than a billion times!" 


"| am sure every other superhero has a good thing to say about SuperBook too. Take 
Blitz. His AskMeAnything interview won back the hearts of his fans. They were thinking 
that he was on experimental drugs all this time. It was only when he revealed that his 
father was Hurricane that his powers made sense." By the way, how is Hart doing 


these days? 


"Much better," said Steve. "He got professional help. The sentinels were handed back 
to S.H.I.M. They are developing a new quantum cryptographic algorithm that will be 
much more secure." 


"So, | guess we are safe until the next supervillain shows up," said Captain Obvious 


hesitantly. 


"Hey, at least the beacon works," said Steve, and the crowd burst into laughter. 
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In this final chapter, we looked at various approaches to ake your Django application 
stable, reliable, and fast. In other words, to make it production-ready. While system 
administration might be an entire discipline in itself, a fair Knowledge of the web stack is 


第 十 一 章 部 署 到 生成 环境 之 前 的 准备 工作 169 


essential. We explored several hosting options, including PaaS and VPS. 


We also looked at several automated deployment tools and a typical deployment scenario. 
Finally, we covered several techniques to improve frontend and backend performance. 


The ost iportant ilestone of a website is finishing and taking it to production. However, it 
is by no means the end of your development journey. There will be new features, alterations, 
and rewrites. 


very tie you revisit the code, use the opportunity to take a step back and find a cleaner 
design, identify a hidden pattern, or think of a better implementation. Other developers, or 
sometimes your future self, will thank you for it. 


I'm digging a hole for you guys. 


